Moving to ServiceNow Case Management for Customers: Migration Considerations

Moving case work into ServiceNow Case Management for Customers means deciding what case history to carry across, how legacy statuses and custom fields map, when to cut over and how to prove that customer communication never stopped. The sections below work through the data inventory and quality assessment, process mapping and redesign, cutover timing, customer communication and training, testing and validation, rollback planning and post-migration support, with later sections on status mapping, attachments that break in transit and rehearsing the rollback.

Data Inventory and Assessment

Start by inventorying what data you need to migrate. Typical case management data includes: case records with status, priority, description, and resolution; customer contact information and account associations; case history and comments; attachments and related records; and any custom fields or case types. Before deciding what to migrate, assess data quality in your source system. Case records with missing required fields or malformed data are better handled before migration than after.

Decisions to make: should you migrate only open cases or include closed cases as well? Closed cases take storage space and add complexity to the migration, but you may need them for historical audit trails or customer reference. Should you migrate custom fields if they are not used in the new system? Evaluate whether that data is valuable enough to recreate in ServiceNow or whether it can be archived separately. Should you normalize customer names, contact formats, and case type names during migration or migrate as-is and fix afterward? Normalizing during migration increases effort upfront but results in cleaner data in the new system.

Evidence to keep: export your source system data before starting the migration. Keep a copy of the pre-migration inventory (count of cases by status, age distribution, custom field usage). This serves as your baseline to validate that the migration succeeded.

Process Mapping and Redesign

Your current case management process may depend on features or workflows in your old system that work differently in ServiceNow. Map your current end-to-end case process: how does a case enter the system (email, web form, phone), how is it routed, how do teams collaborate, how are status and priority determined, how are customers notified of updates, and how are cases closed and archived?

Then map how that process works in ServiceNow Customer Service Management. Identify gaps: does ServiceNow support automatic routing to the same teams using the same business logic? Does it support the same notification rules? Can you replicate custom case types or do you need to consolidate?

Common adjustments: business rules and workflows in the old system may need to be recreated in ServiceNow using business rules, flow designer, or automation engine. Email forwarding addresses or integration endpoints may need to be updated if the new system uses different API endpoints. Custom email templates for customer notifications must be recreated in ServiceNow.

Decisions: identify essential process features that must work on day one versus nice-to-haves that can be implemented after cutover. Focus migration effort on case creation, routing, and customer notification. Defer advanced analytics or reporting until after cutover when the team is stable.

Cutover Strategy and Timing

Two main cutover approaches: parallel cutover (run both systems simultaneously for a period) and direct cutover (switch to ServiceNow on a specific date and retire the old system). Parallel cutover is safer but requires data synchronization between systems and doubles the team’s workload. Direct cutover is faster and avoids synchronization complexity but requires more confidence that the new system is ready.

For most case management migrations, a hybrid approach works well: start parallel cutover for existing staff and customers while you validate data and workflows. Once you are confident the new system is stable, set a cutover date, migrate final data and active cases, and retire the old system. The length of the parallel period depends on how quickly the new system proves stable.

Timing considerations: schedule the cutover during a low-volume period if possible (not month-end, not before a major business event). Plan cutover for early in the week so you have weekday support if issues arise. Do not schedule cutover late Friday or during a holiday blackout. If you have global customers, pick a time when support teams in multiple regions can be available.

Cutover plan: document the exact sequence of steps (final data export, transformation, import into ServiceNow, team training completion, go-live announcement, old system shutdown). Include rollback procedures in case critical issues occur: how quickly can you switch customers back to the old system if needed?

Customer Communication and Training

Customers need to understand what is changing and when. Communicate the migration well before cutover. Tell customers when the system will be unavailable (if applicable), what will change in their experience (login URL, case portal appearance, communication channels), and what stays the same (service levels, response time, how they submit cases).

For internal teams, training should cover: how cases are created and assigned in ServiceNow; how to add comments and update status; how to send customer notifications; and how to run their daily case workload reports. Hands-on training with real cases from your test environment is more effective than reading documentation. Plan training well before cutover so staff can practice and build confidence.

Support during cutover: have an escalation process and dedicated support person ready for the first week. Customers or staff will encounter issues or confusion. Rapid response to those early problems avoids larger problems later.

Testing and Validation

Test plan should cover: data migration (run a full dry-run migration to test environment and verify all data arrived correctly); workflow and routing (test that cases are routed to correct teams using correct business logic); customer communication (send test emails or notifications and verify they arrive correctly); and end-to-end case creation and resolution (simulate a complete case from creation to closure to verify the workflow works).

Entry and exit criteria for testing: entry criteria include all case management configuration complete, all integrations connected, all test data loaded into test environment, and test team trained on ServiceNow. Exit criteria include all test cases passing, no critical issues found, data validation successful, performance testing shows acceptable response times, and both internal teams and sample customers have validated the test environment.

Regression testing: before cutover, verify that historical cases migrated correctly by spot-checking a sample across different case types, ages, and statuses. Run a report of case counts by status in ServiceNow and compare it to the source system to ensure no cases were lost.

Risk Mitigation and Rollback

Major risks in case management migration: data loss or corruption during import (mitigate by running multiple dry-run migrations and keeping detailed logs); process workflows not working in ServiceNow (mitigate by testing extensively before cutover); customer communication channels failing after cutover (mitigate by testing integrations and having a support process ready); and team not ready or trained adequately (mitigate by running hands-on training sessions early and providing documentation).

Rollback plan: if critical issues occur after cutover, can you revert to the old system? Document the rollback procedure: stop new data entry into ServiceNow, restore customers to the old system, and communicate the delay. Rollback is easiest if you ran parallel cutover; direct cutover makes rollback harder because some data may have entered the new system already.

Post-Migration Support and Optimization

Do not treat migration as complete on day one. Plan for a period of enhanced support after cutover, when unexpected issues are most likely. Keep the old system available in read-only mode for as long as teams need it to reference historical data. Once the early period has passed, shift focus to optimization: identify process improvements that were not ready for cutover and implement them. Gather feedback from teams and customers on what is working and what needs adjustment.

Mapping legacy statuses without losing meaning

Legacy statuses rarely map one to one. A status called “with supplier” may cover two different waits, and a status called “done” may hide cases that were never really resolved. Before any data moves, build a mapping table that asks what each legacy status means in practice and where it should land.

Where a legacy status cannot be mapped cleanly, record the ambiguity rather than forcing it. The cases concerned become the first items reviewed after cutover.

Attachments and links that break in transit

1. Export attachments with their parent case identifier, not only their file names, because file names repeat across customers.
2. Find links inside case text that point to the legacy system and decide whether each one is rewritten, redirected or kept as a historical reference.
3. Check that customers’ bookmarked case numbers still resolve, or send them a clear message about the new reference.
4. Test a sample of attachments from the largest cases, since size limits are where transfers most often fail quietly.

Rehearsing the rollback

A rollback rehearsal is worth more than a second full dry run. Walk through the steps in order, with the people who would carry them out, and time each one. Note the point after which rolling back loses new work, because that point defines how long you can wait before committing. The rehearsal should also re-run the acceptance scenarios on the rolled-back data, so the team knows the old state is usable and not merely restored.

Questions about migrating case history

Should closed cases from the legacy system be migrated at all?

Migrate the closed cases a customer or auditor is likely to ask about, and archive the rest in a readable form. Migrating everything can slow the new system for little benefit, and the audit trail evidence post covers what the record should show for an audit.

Can timestamps be kept as they were recorded?

They can, but test whether the new system overwrites created and updated values during import. Some teams only discover this when a breach report changes overnight.

Who should approve the mapping table?

The owner of the legacy process, with a sign-off from the people who will work the cases afterwards. Mapping errors surface in daily work long after the migration team has moved on.

Mapping errors are cheapest to fix on paper, so settle the status table before the first dry run is booked.

Related guides: ServiceNow Case Management for Customers: Security and Access Design.