ServiceNow Data Migration and Import Sets: Security and Access Design

Role Model for Data Migration Access

Data migration often involves sensitive data: customer records, employee information, financial data, and security configurations. The Data Migration Specialist designs the migration strategy, creates import sets, and executes the migration; they need write access to import sets and transformation rules. The Data Governance Officer reviews what data is being migrated, confirms it complies with data retention policies, and ensures sensitive data is handled appropriately. The CMDB Administrator ensures configuration item relationships are preserved during migration; they have authority to approve CI migration strategy. The Security Officer reviews whether migration exposes sensitive data and whether transformation rules correctly mask or exclude restricted information. The Compliance Officer verifies that data migration complies with regulations (GDPR right to be forgotten, data residency requirements) and data privacy commitments. The IT Architect sets migration strategy: which systems are source systems, which are targets, and how data flows between them.

Data Staging and Segregation of Duties

Import sets are staged data that has not yet been committed to the production system. Stage import sets in a separate environment or separate tables so they do not mix with production data. The Data Migration Specialist prepares data and runs test transformations, but should not have direct write access to production tables; transformations are executed by a controlled process (scheduled or manually approved by the Migration Manager) that logs all changes. This segregation of duties prevents a specialist from silently modifying production data through transformation rules. Access controls with record-level conditions, or query business rules, should be applied to import set tables so that specialists see only data relevant to their migration task, not the entire dataset.

PII and Sensitive Data Handling

Personal Identifiable Information (PII) and protected health information (PHI) require special handling during migration. Do not include PII in test data; use synthetic or masked data for testing. If production data must be used for testing (e.g., to validate a complex transformation), use only a minimal sample and mask sensitive fields. Do not migrate data that is subject to GDPR right to be forgotten or similar regulations unless the data owner has explicitly requested retention. Document which data is migrated and why; if migration is later questioned, documentation supports justification.

Transformation rules that mask or transform PII should be tested to ensure they work correctly. A transformation that should mask email addresses should be verified to mask all email addresses, not just some. A transformation that should hash passwords should be verified to not include the original password in logs or intermediate files. Test these transformations explicitly with synthetic or masked values that mimic real PII to confirm no data leakage occurs.

Migration Audit Trail and Verification

Enable audit logging for all data migration activities: which records were imported, from what source, when, and with what transformation rules. If production data is later questioned, audit logs allow investigation of whether the data was correctly imported or whether something went wrong. Maintain audit logs for data migrations for as long as your compliance obligations require, since investigations may occur years after the migration.

Before committing migration data to production, perform a verification check: count source records and compare to imported record count, spot-check a sample of records to verify transformations worked correctly, and confirm that relationships between tables are intact (incident linked to correct CI, change linked to correct change manager). If verification finds discrepancies, stop the migration, investigate, and re-run after issues are fixed. Never commit a migration that has incomplete verification.

Data Residency and Compliance

Verify that migrated data complies with data residency requirements (e.g., EU customer data must remain in EU). If migrating to a new ServiceNow instance in a different geographic region, confirm that data handling complies with regional regulations. Sensitive data that must be encrypted in transit and at rest should be encrypted during migration; verify encryption is working correctly. If migration involves external vendors or contractors, ensure data processing agreements (DPAs) are in place and the contractor complies with your organization’s data security standards.

Post-Migration Validation and Reconciliation

After migration is complete and data is committed to production, perform post-migration validation: run queries to verify counts, spot-check records, confirm critical integrations still work. If validation discovers issues (missing records, incorrect data), determine whether to use migration rollback (restore from pre-migration backup) or selective correction (update incorrect records). Document all corrections and the reason for each; if auditors later review the migration, corrections should be traceable.

Deciding who may read raw staging rows before the first load

A staging table is where a migration’s problems first become visible, and it is also where a careless grant exposes the most data in the least obvious way. An import set holds a full copy of whatever the source sent, including the columns the transform map later drops or masks. Someone who was never meant to see salaries, national identifiers or payment fragments can still open a staging table if its access rules were copied from a generic reference-data template. The first call for the security lead is therefore not which role gets write access, but which people need to read raw rows at all, and for how long.

Settle that question before the import set exists, using the data migration and import sets overview as the map of related design work. Ask the data owner which source fields are restricted by law, by contract or by internal policy, then ask which people on the migration team need to see those fields to debug a transform. In many programs the answer is a small group of two or three named leads, and their need often ends once the trial loads are stable. Everyone else should work from row counts, error summaries and masked samples. Write that split into the access design as a list of named roles, not as a general statement that data is handled carefully, because the second version cannot be audited. The data classification in service workflows article covers how a classification should change workflow handling, which is where this result belongs.

Separating the people who build transforms from the people who release them

A common control gap in a migration is not an outsider with access. It is one analyst who writes the transform map, tests it against live staging rows, and then starts the production load because the same role grants both abilities. Splitting those duties costs a little time per run and removes the situation where a script edit reaches production with no second reader. The practical split is between an author role that can change maps and scripts in a development or staging scope, and a release role that can run a load against production tables after reviewing the run summary.

Keep transform scripts under the same change control as any other customization. The instance security and access control guide covers the platform rules that apply. A map that masks email addresses is code that decides what production stores, so a change to it deserves a record, a reviewer and a note of which source file it was tested against. Teams that treat transform maps as data configuration tend to discover this only after a reconciliation shows that one column is populated for half the rows.

What a reviewer should look for in a transform script

A reviewer should check three things that a functional tester usually misses. First, whether the script writes any restricted value to a log, a journal field or an error message, because a failed row often gets logged in full. Second, whether a default value silently replaces a missing restricted field, since a blank national identifier that becomes a placeholder string can pass validation and then be treated as real by downstream lookups. Third, whether the script depends on a lookup table whose own access rules are looser than the target table’s.

An ordered access review to run before the first production load

Run the review as a sequence rather than as one sign-off meeting, since a later step only means something once the earlier one has passed. A group that skips to the approval step often approves a design nobody has tested.

1. Classify every source column as public, internal, confidential or restricted, and record the classification next to the mapping, not in a separate workbook.
2. List every role that can reach the import set table, the transform map, the target table and any error or log table, and remove roles that no current task requires.
3. Confirm that the staging table’s read rules hide restricted columns from anyone outside the named migration leads, and test this by signing in as a representative of each role, following the approach in the access controls review.
4. Trace one restricted value from the source file through the transform to the target field and check every place it is written in between, including logs and attachments.
5. Set a purge date for staged rows and record who approves the purge, so that the staging area does not become a second copy of the legacy system.
6. Only then request the release approval for the first production run, and keep the signed review with the audit trail evidence for the migration.

Failure modes that appear after go-live

Security problems in migrations often show up weeks after the load has finished. A report built on the staging table for debugging gets scheduled and shared with a wider audience. An integration user created for the load keeps its elevated role and is later reused by an unrelated process. A retention rule for the target table is set, but nobody applies it to the staging copies, which were never classified as records in their own right. The defense is to put the staging table on the same retention and review calendar as the data it holds, and to remove the load account’s elevated role as soon as the final reconciliation is accepted.

Is a dedicated migration service account always necessary?

In many cases yes, but it should be scoped to the one job it runs. A personal administrator account used for a load is hard to attribute later, and an account with broad rights is hard to justify to an auditor. A narrow account, with its own name, its own rights and a documented owner, makes the audit trail readable.

Should restricted fields be dropped before they reach staging?

Only when the business does not need them for reconciliation or for the rare correction that follows a failed row. Dropping them early makes the staging table safer but makes it impossible to prove that a value arrived intact, so many teams keep a hashed or truncated form of the value for matching instead of the value itself.

What should happen when a migration lead changes role mid-program?

Their staging and load rights should be removed on the same day, and the change should be recorded against the migration plan. Staff turnover is common in long migrations, and access that was granted for one phase tends to outlive that phase unless someone is responsible for removing it.

Import set security: table names, roles and script hooks

An import set in ServiceNow loads raw source rows into a staging table before a transform map writes them to a target table, so access to the staging table is access to the full source data. The deciding control is who can read those staging rows, not who can run the load.

These are common out-of-box names. Check them on your own instance and release, because labels and defaults change between releases and custom import tables will differ.

Transform scripts run at defined points: onStart, onBefore, onAfter, onReject and onComplete. A script in onBefore can set ignore to skip a row, which is where masking and exclusion rules usually live, so these hooks deserve the same change review as any business rule. The wider design is laid out in the data migration and import sets overview, and the platform side is covered by the instance security and access control guide.

Example (hypothetical): a team loads a staff file with a national identifier column. The author masks that column in onBefore. A different person holding import_transformer runs the production load after reading the run summary, and the staging rows are purged once reconciliation is signed off. The cutover and reconciliation service describes that sign-off step.

Which role should be allowed to read staging rows?

Give read access on import set tables to the few named leads who debug transforms, and only during trial loads. Keep import_admin away from broad groups. Everyone else can work from run records, error counts and masked samples.

Where do transform scripts leak restricted values?

The usual places are log statements, error messages on rejected rows and journal fields written in onAfter. A failed row can be logged whole, so a script should log the row identifier and the failure reason, never the restricted column values.

Can the person who writes a map also run it in production?

They can if one role holds both abilities, and that is the gap to close. Give the author a development scope, and give a release owner who did not write the map the right to run the production load after reading the run summary.