ServiceNow Data Migration and Import Sets Requirements Workshop Questions

These workshop questions help a project team settle what data moves to ServiceNow and how the move is validated. They cover data inventory and quality, field mapping, cutover strategy, validation, historical archives and who maintains the data afterwards.

The workshop questions for a data migration settle what moves and how it is proven: which source data exists and how clean it is, how fields map and transform, whether cutover is a freeze or a parallel run, how the load is validated and reconciled, what happens to history and archives, and who keeps improving the data afterwards. The questions below follow that order and end with the ones that expose hidden dependencies.

Data Inventory and Quality Assessment

The first set of questions focuses on understanding what data exists in legacy systems and its quality. How much data will migrate? Is all of it needed in ServiceNow, or just active data? What is the data quality? Are there duplicates, missing values, inconsistent formats? How current is the data (is it still being used or is it historical)?

A data inventory project should catalog all source systems, all tables that might be migrated, data volumes, and known quality issues. Common quality issues include: duplicate records (same customer with multiple IDs), inconsistent formatting (phone numbers formatted differently in different systems), missing values (required fields left blank), and stale data (records not updated in years).

Data discovery often reveals data that was never supposed to exist. A customer table that should have one million records actually has three million (duplicates). A status field should have three values but has ten (data entry errors and code changes over the years). An address field contains notes instead of addresses. These discoveries should be documented.

A practical approach to data quality is: define what “good enough” means for each dataset. Fully clean data is rarely achievable. A high but imperfect standard may be acceptable depending on risk. High-risk data (financial records, compliance data) should be cleaned to higher standards. Lower-risk data (internal notes, historical records) can be migrated with lower quality standards.

The warning sign is underestimating data cleaning effort. Teams often discover during migration that cleaning takes longer than expected. Plan for data cleaning during requirements gathering and budget time for it.

Data Mapping and Transformation Logic

The next set of questions focuses on how data from source systems maps to ServiceNow tables and fields. Will every field from the source map to ServiceNow? Will some fields be consolidated or transformed? Will data be enriched during migration (adding new data that was not in the source)?

A data mapping document shows: source table, target table, source field, target field, transformation rule (if any). For example: legacy system customer_id maps to ServiceNow company_name (requires lookup table to convert IDs to names). Legacy status_code (1=active, 2=inactive) maps to ServiceNow state (must transform values). A comprehensive mapping document prevents surprises during implementation.

Transformation logic ranges from simple (copy data as-is) to complex (join data from multiple source tables, calculate derived values, apply business rules). Simple transformations are easier to test and less error-prone. Complex transformations should be tested thoroughly and documented clearly.

A related question is handling legacy data that does not fit ServiceNow model. If a legacy system had flexible custom fields and ServiceNow has structured fields, some legacy data cannot be migrated. Decide upfront: will unmappable data be lost, stored in a notes field, or migrated to a separate historical database?

Data enrichment during migration should be intentional. Adding data that was not in the source (for example, calculating costs from supplier contracts) is valuable but adds complexity and requires careful validation. Enrichment should be explicitly planned, not discovered during implementation.

Cutover Strategy and Parallel Running

Cutover strategy determines whether data migration happens all at once or in phases. Options include: big bang (all data migrates on cutover date), phased (critical data first, then others), or pilot (one location or department first, then expand).

Big bang is fastest but riskiest. If data migration has errors, you discover them when the system is live and users are waiting. Big bang works well if data quality is high and migration has been extensively tested. Large-scale migrations with many legacy systems should typically use phased or pilot approach.

Phased cutover reduces risk by migrating critical data first (active customers, open orders), proving out the migration process, discovering issues, and fixing them before migrating remaining data. Phased migrations take longer but reduce crisis risk.

Pilot cutover starts with one location or department. Once the pilot is stable and users are trained, expand to other locations. Pilot gives teams time to learn and adapt before organisation-wide rollout.

A critical question is parallel running: do you maintain both legacy and new systems during transition? Running in parallel (continuing to use legacy systems while ServiceNow is used in parallel) provides safety but requires duplicate data entry or complex synchronisation. Parallel running should last only as long as validation needs. If parallel running drags on past that point, either ServiceNow has critical issues or you are being overly cautious.

Data Validation and Reconciliation

After data migrates, validation confirms that data was transferred correctly. The validation approach should be planned upfront. Common validation activities include: record counts (is the count of migrated records equal to source count?), sample record inspection (do random samples of migrated records match source records?), business rule testing (do calculated fields show correct values?), and range checking (are values within expected ranges?).

Data reconciliation compares migrated data to source data and identifies discrepancies. Discrepancies might be legitimate (data was cleaned during migration) or errors (transformation rules did not work correctly). All discrepancies should be investigated and resolved before users start working with data.

Automated validation is more thorough than manual spot-checking. Write scripts that compare migrated records to source records, flagging discrepancies. Scripts can check every record, not just samples. Automated validation should be run for high-risk data migrations.

A reconciliation holdback period (few days after go-live where data can be corrected) allows fixing validation issues that surface after users start working. After the holdback period, data is considered final and no longer corrected.

Historical Data and Archive Strategy

A decision about historical data is often overlooked: will you migrate all historical data (years of closed records) or only recent or active data? Migrating all historical data increases volume, complexity, and migration time. Keeping only active data reduces volume but loses historical context.

A practical approach is: migrate active and recent data (the period your teams need for daily work) into ServiceNow. Archive older data separately (data warehouse, archive database) where it can be accessed if needed but does not clutter the active system. This balance maintains historical context without overwhelming the system.

Another historical question is whether to migrate audit trails and change history. ServiceNow tracks who modified records and when, but legacy systems may not. If audit trails are required for compliance, they should be migrated. If not required, migration can focus on current state only.

Post-Migration Support and Data Quality Improvement

Data migration does not end on go-live. A post-migration period should include dedicated support to address data issues that users discover, lasting until new issues stop appearing. Data quality improvements often continue well after migration as users clean up data they find problematic.

Common post-migration work includes: fixing duplicates that surface as users work (two customer records that should be one), reconciling data that did not migrate cleanly, and building reports that allow users to identify and fix data issues. Plan for this work upfront rather than treating it as unexpected.

A final question is data preservation. Keep a copy of legacy system data for as long as your retention policy and audit needs require. If data questions arise, the legacy data provides reference. Once that period ends, legacy systems can typically be decommissioned, freeing support resources.

The warning sign is data quality problems discovered after go-live. Avoid this by investing in data validation and reconciliation before cutover. Time spent on thorough validation before cutover is worth it compared with the firefighting that follows when problems surface after go-live.

Questions that expose hidden dependencies

A requirements workshop for a migration is most useful when it finds the dependencies that nobody has written down. Most teams can list the datasets they expect to move. Far fewer can say which records point at which other records, which fields are populated only because a manual process fills them in, or which values in the legacy system carry a meaning that exists only in someone’s head. The questions below are designed to surface those gaps. Every question comes with a sample of the vague reply that should trigger a second round, since vagueness is the most useful signal a workshop yields.

How to run the workshop so the answers are usable

Workshops often fail when they produce a long list of opinions that nobody converts into decisions. Structure the session so that each block ends with a written outcome. Start with the datasets, move to the references between them, then cover the people who own each field, and finish with the cutover expectations. Assign one person to write the answers into a register during the session, not afterwards, because the nuance in a reply disappears within a day.

1. Confirm the list of source datasets and the business owner for each one before discussing any field.
2. For each dataset, identify the references to other datasets and mark which ones must be complete before the load.
3. Ask the owner to name the codes and manual fields that carry meaning the system does not show.
4. Record the cutover expectations as they are said, then test each one against the rehearsal plan later.
5. Send the register back to the attendees within the week and ask them to correct anything that was misrecorded.

Answers that should change the plan

Some answers force a change in scope or sequence, and the workshop should flag them as such. A reference that must be complete before a large dataset loads moves that reference earlier in the program. A manual field that is essential but maintained in a spreadsheet often needs a source owner and an extract before it can be migrated at all. A business expectation that all history must be live on day one is a scope decision and belongs to the business owner, not to the workshop group.

Questions about running the workshop

Who should attend?

The business owners of the datasets, the owners of the legacy systems and someone who will build the mapping. Leave out senior sponsors for the detailed field questions, but bring them in for the scope and cutover sections, where their decisions are needed.

Should the workshop cover the target platform design?

Only where the design affects the data. Discussing forms, catalog items or dashboards in a data workshop pulls attention away from the questions that determine what gets loaded. Park those topics in a separate session.

What do we do with questions nobody can answer?

Record them with an owner and a date for an answer, and keep the dataset out of the first load until the answer arrives. A question left open in the register is manageable. A question that is quietly assumed becomes a defect after cutover.

Next step

The answers from a workshop feed directly into the scope and the roles that will sign off each dataset. Naming those owners is the job of the roles and RACI guide, and the post on data source governance covers which source is authoritative for each field.