ServiceNow Data Migration and Import Sets Governance Model

A data migration and import sets governance model is the set of decisions, owners and records that control how data reaches ServiceNow. It sets out who approves each load, which exceptions are accepted and how each migrated dataset is signed off.

Decision Forums: Data Migration Board

A Data Migration Board (or Migration Steering Committee) meets to oversee data migrations. Membership includes: Data Governance lead, source system owner, target system owner (ServiceNow), IT Operations (who handles infrastructure), Data Quality (who validates data). The board reviews: data migration plans (what data is being moved, why, timeline), data quality assessments (what quality issues exist, how will they be fixed), risks and mitigation plans (what could go wrong, how will we handle it), and progress (are migrations on track, what blockers exist). The board approves major migrations and escalates issues.

Standards for Data Quality and Validation

Data migrations often uncover quality issues in source systems: duplicate records, incomplete data, invalid values. Define standards before migration: what data quality is acceptable, what must be fixed before migration, what can be fixed after? Standards typically include: no duplicate records (merge or delete duplicates before migration), required fields populated (do not migrate records with missing critical data), referential integrity (if records reference others, both must exist), and data format consistency (dates in one format, phone numbers in one format). Apply standards to both source data (clean before migration) and target data (validate after migration).

Change Control for Data Migrations

Large data migrations can impact production if something goes wrong. Treat migrations as significant changes: require planning, testing, approval, and rollback capability. Plan the migration: schedule it during low-usage periods, communicate timing to users, prepare support resources. Test the migration: run a practice migration in a test environment, validate results, identify issues. Approve before proceeding: migration board reviews test results and approves going to production. Execute and monitor: migration happens, system is monitored for problems. If problems occur, rollback: restore from backups to the pre-migration state. Do not make migrations on-demand; schedule them on a regular cadence (monthly or quarterly).

Ownership and Accountability

Clear ownership is essential. Who owns the migration: the data governance team, a project manager, the business owner of the data? Ownership includes: planning the migration, ensuring data quality, validating results, and troubleshooting if something goes wrong. The owner is accountable to stakeholders: the business owner is accountable for data accuracy and timeliness, IT is accountable for system stability during migration, Data Governance is accountable for data quality standards. If a migration introduces errors, the owner must remediate them. Clear ownership ensures accountability and prevents work from being orphaned.

Documentation and Audit Trail

Document all migrations: what data was migrated, when, how many records, what issues were discovered, how were they resolved, who approved the migration. Maintain a migration log: a record of every migration executed, with results and outcomes. This log is valuable if issues arise: you can trace back to see what data was migrated when, and investigate if needed. Maintain immutable audit trail: who performed the migration, when, what was the source data, what was the result. This audit trail is evidence of control and due diligence if a data issue later comes up.

Rollback and Recovery Procedures

Before any migration, ensure rollback is possible. Do you have a backup of the data before migration? Can you restore the backup if needed? What is the maximum time you can be in a rolled-back state without impacting business? Plan rollback steps: if data migration causes problems, how quickly can you restore? Rollback to backups is usually fastest: restore the pre-migration backup and resume business with yesterday’s data. An alternative is to leave migrated data in place but flag it as questionable until issues are investigated. Define rollback criteria: if a significant portion of records fails validation, or if critical data integrity issues are discovered, rollback immediately.

Validation and Sign-Off

After migration, validate the results: do record counts match expectations, are all required fields populated, is data accurate? Use automated validation: scripts that check record counts, flag missing data, verify referential integrity. Use manual validation: business owners spot-check records and confirm they are correct. Sign-off is formal: when validation is complete and issues are resolved, get approval from the business owner, data governance, and IT. Sign-off means you accept the migrated data and take ownership of it going forward. Do not take sign-off lightly; it is your commitment that the data is good.

Performance and Monitoring During Migration

Large migrations can impact system performance: while migration is running, the system may be slow or unavailable for users. Manage this by: migrating during low-usage periods (evening, night, weekend), performing migrations in batches (migrate subset of records, then next batch, rather than all at once), and monitoring system resources during migration (if CPU or database load is too high, pause and resume later). Communicate to users: let them know when the system will be unavailable or slow due to migration. Provide realistic estimates: tell users the system will be unavailable from 10 PM to 2 AM, not “overnight” (which is vague).

Who decides what, and what must be written down

Governance for a data migration often fails in a predictable way. Everyone agrees that the board approves major loads, but nobody has written down which smaller decisions the board never sees. A mapping change is made by an integration developer on a Tuesday, a reject category is reclassified by an analyst, and a historical dataset is dropped from scope in a hallway conversation. Each decision looks minor, and together they change what the business ends up with. A workable model names the decision, the person who makes it, the record that proves it was made, and the point at which it has to go up a level.

Use the table below as the skeleton of the register. Its rows are decisions rather than committees, since auditors and business owners later trace decisions, not meetings.

Exception registers that people actually read

An exception is a known departure from the agreed standard, accepted on purpose. It is different from an error, which nobody has accepted. Keeping the two apart matters because an exception that was never formally recorded looks, six months later, exactly like an error that was ignored. A register for exceptions should hold the dataset, the rule being departed from, the number of affected records as measured at the time, the business reason, the owner, and a review date. Keep it short enough that a senior sponsor can read it in one sitting. A register with several hundred open lines is not governance, because nobody can act on it.

A review rhythm for the period after go-live

Governance often tightens during the load and then slackens once the migration is declared finished. That is the period when quality problems surface, because users start working with the data at scale. A simple rhythm keeps the decision record alive without holding meetings for their own sake.

1. Review the open exceptions with the business owners at a fixed point after each wave, and close any that were resolved by the work of the wave.
2. Check the reject register for categories with no activity, which often means the reject was never worked rather than fixed.
3. Confirm that any delta loads still running from the legacy side are covered by a current approval, since they are production loads in all but name.
4. Record the final acceptance of each dataset and move its exceptions to the post-migration support register with an owner.

Handling disagreement between owners

Disagreements often sit between the people who want the data clean and the people who need the cutover on time. The governance model should say in advance what happens when they conflict. A common rule is that the business owner decides whether a gap is acceptable, the platform owner decides whether it can be loaded without damaging the platform, and the governance lead decides whether the decision is recorded correctly. Writing those three roles into the model before the dispute arrives lets the conversation stay on the facts.

Questions governance leads ask

Does every change to a transform map need board approval?

No. Route small corrections through the platform owner with a recorded version change, and reserve the board for changes that alter scope, the meaning of a business field, or the sequence of a cutover. Sending every edit to the board slows the program and teaches people to avoid the process.

How long should an exception stay open?

Until its review date, and then either closed or renewed with a fresh reason. Renewing an exception with no new reason amounts to deciding to stop reviewing it, and that decision goes up a level.

Who holds the register once the migration program closes?

The business owner of each dataset holds the open exceptions for that data, and the governance lead keeps the consolidated view. The program closing does not close the exceptions, so the register must move with the data rather than stay with the project.

Next step

A governance model only works when the platform controls behind it are in place, including the access rules that decide who can run a load. The security and access design guide covers that side. The platform operating model and governance service page covers who decides what across the platform.