Moving to ServiceNow Business Continuity Management: Migration Considerations

Inventorying Business Functions and Current State

Before migrating to Business Continuity Management, conduct a thorough inventory of existing business continuity plans and recovery procedures. Locate all existing documentation: formal BCPs if they exist, disaster recovery procedures for IT systems, manual workarounds documented for critical processes, contact lists for emergency teams, and any recovery runbooks. This documentation may be scattered across multiple locations—shared drives, email, wiki pages, or even notebooks.

For each critical business function, record its recovery time objective (RTO: maximum acceptable downtime) and recovery point objective (RPO: acceptable data loss). If these aren’t formally defined, involve business owners in establishing them. Business continuity priorities differ: a financial transaction system may need a much shorter RTO than a reporting system, and each business owner should set the figure for their own function. Understanding these priorities before migration helps you configure Business Continuity Management appropriately and allocate resources correctly.

Mapping Infrastructure and Asset Dependencies

Business continuity relies on understanding what infrastructure supports each critical function. Create dependency maps for critical services: identify which applications run on which servers, which databases are required, which network paths are critical, which third-party services are dependencies. Business Continuity Management links BCPs to supporting infrastructure; incomplete dependency information makes recovery procedures unreliable. If your CMDB is incomplete, remediate it before or as part of Business Continuity Management migration.

Identify single points of failure in your dependencies. A critical function that depends on one server or network link is vulnerable; if that single point fails and is not part of your recovery procedure, your BCP won’t work as intended. Business Continuity Management can highlight these gaps when you document dependencies, giving you an opportunity to address them through redundancy or specific recovery procedures.

Validating and Updating Recovery Procedures

Many organisations have BCPs on paper that have never been tested. Before migration, audit recovery procedures for accuracy: do they reflect current infrastructure, applications, and contact information? Are they detailed enough for someone unfamiliar with the system to follow? Do they include verification steps to confirm recovery was successful? Stale or incomplete procedures often reflect outdated systems that no longer exist or describe procedures that won’t actually work.

Review contact lists and escalation procedures. Are emergency contact phone numbers and email addresses current? Have team members changed? Are out-of-office plans in place for critical recovery roles? Migrating inaccurate contact information into Business Continuity Management creates a false sense of preparedness; during an actual crisis, you discover that procedures and contact lists are unreliable.

If procedures don’t exist for critical systems, developing them is part of the migration effort. Involve system owners and operators who understand recovery steps, identify manual workarounds that would be needed, and document realistic timelines for recovery. This is an opportunity to establish standardised runbook documentation that goes beyond what existed before.

Planning Cutover and Data Migration Strategy

Business Continuity Management can operate in parallel with legacy tools during a transition period, or you can migrate fully and retire legacy tools. Full migration requires that all critical BCPs are in the system and validated before cutover. Parallel operation requires that you maintain both systems—if infrastructure changes occur, both systems must be updated to stay in sync. Most organisations choose a phased approach: migrate critical functions first, validate them, then migrate secondary functions over subsequent weeks.

Plan how you will handle BCPs that reference external systems or legacy documentation. Some recovery procedures may reference detailed step-by-step guides stored outside of Business Continuity Management. Decide whether to migrate these references into Business Continuity Management (embedding the procedures directly) or maintain external documentation with links from Business Continuity Management.

Testing Schedule and Validation Framework

Establish a testing strategy before go-live. Critical business functions should undergo tabletop exercises (walk-through reviews of procedures, no actual recovery) before production cutover. High-value functions benefit from full recovery tests in controlled environments to validate procedures actually work. Define how frequently each BCP must be tested post-migration: critical functions at the interval your governance sets, less critical functions at a longer one. Schedule tests and assign owners responsible for scheduling and documenting results.

Use testing results to iterate on procedures. A test often reveals assumptions that are no longer valid, contact information that needs updating, or steps that are ambiguous or missing. Business Continuity Management should capture test results and track improvements made based on test findings. This creates an audit trail showing that BCPs are actively maintained and regularly validated.

Start with the records you will not carry across

Many migration plans begin by listing what to move. A more useful first step is to list what should not move, and to agree that with the business before any data is mapped. Old continuity binders often contain material that was only ever meaningful to the person who wrote it: draft plans that were never approved, superseded versions kept for reference, and contact entries for people who left years ago. Loading all of it gives the new platform the same clutter and a false impression of how much is actually governed.

A workable rule is to migrate only records that have a current owner, an approval state and a date. Anything that lacks one goes to a holding list with a decision date. Teams often resist this because it feels like losing history, but the history can be kept in a read-only archive. What must not happen is for an unapproved draft to appear, with the same authority as an approved plan, in the first dashboard a director sees.

Map fields to decisions, not to labels

Field mapping is often done column by column, which produces a tidy spreadsheet and a poor result. Each field in the legacy document answers a question someone uses during a disruption, such as who can approve a move, how long a service can be down, or where the current runbook lives. Map each field to the decision it supports, then check that the target structure has somewhere to put the answer. If a legacy field has no decision behind it, ask whether it is still needed before creating a home for it.

Ordered steps for the cutover decision

1. Freeze edits to the legacy plans for the migrated scope, and announce the freeze to every plan owner in writing.
2. Reconcile counts: the number of plans, approved plans, services and named owners in the legacy set must match the number loaded, with every difference explained.
3. Re-assign plan ownership to current role holders, not to the individuals named in the old document, using the same logic as a configuration ownership model.
4. Confirm the access model in the target environment: who can edit a plan, who can approve one, and who can only read it during an incident. Access rights should be reviewed as part of the move, in the way a periodic access recertification would review them.
5. Spot-check five records in full against their source documents, including one that has a complex dependency.
6. Obtain sign-off from the program owner and the service owners named in the migrated scope before retiring the legacy copy.

Keeping the evidence trail intact

Past test evidence is valuable, and it is easy to lose in a move. If the old exercise reports sit in a shared folder that will be decommissioned, the new platform will show a clean record with no history of testing, which can look worse to an auditor than an honest gap. Import the most recent reports for each in-scope plan, mark them as historical, and link them to the plan version they tested. Where a report refers to a version that no longer exists, say so in the record rather than editing the report.

Questions about migration sequencing

Should we migrate the most critical plans first?

Often, yes, but only after the access model and the approval workflow have been proven on a small group. Critical plans are the least forgiving place to discover a configuration problem, so the first wave should be representative rather than simply the most important.

What do we do with plans that reference systems not yet in the configuration data?

Record the reference as an open dependency with a named owner, and keep the plan in a state that says the dependency is unverified. Do not invent the missing record just to complete the load, because the reconciliation will then appear to pass while the gap remains.

Can a migration also update the recovery objectives?

It should not be the vehicle for that change. Carry the existing objectives across as they were approved, then review them in a separate step. Mixing the two makes it impossible to tell later whether a difference came from the move or from a deliberate decision.

How do we handle staff who used the old documents from memory?

Run a short walk-through with them on the migrated plan before the legacy copy is retired. People who relied on memory often spot a step that was never written down, and that is the moment to add it, not after the next disruption.

Next step for your migration

You can also read the plain-language guide to the module to check the scope with colleagues who have not yet used it; for reconciliation methods in more depth, the data migration validation and cutover article is the companion.

Business continuity migration: RTO and RPO values, import tables and CMDB names to map

RTO is the longest outage a business function can tolerate, and RPO is the longest span of data loss it can accept. Before moving continuity plans into ServiceNow, record both for each function and tie the function to a business service in the CMDB, so a recovery order can be checked against real dependencies.

The names below are common out-of-box values for a migration of this kind. Check them on your own instance and release, because labels and defaults change between releases and the continuity application may label its own fields differently.

Stage everything through an import set first. Loading into a staging table lets you compare row counts and fix owner or group mismatches before a single plan reaches the live record set, and the transform map documents exactly how each legacy column was translated.

Example (hypothetical): a team keeps its payments recovery plan in a spreadsheet with a free-text system list. They create a business service for payments, relate it to the database and application servers it runs on, then load the plan through a transform map so the dependency list can be loaded as relationship records rather than a paragraph. A later review can then ask which plans touch a given server.

Is an RTO the same as an RPO?

No. RTO limits how long a function may be unavailable, while RPO limits how much recent data may be lost. A reporting service might accept a long RTO and a short RPO, so record the two targets separately instead of one combined priority.

Does disaster recovery for the instance replace a continuity plan?

No. Resilience of the ServiceNow platform itself is handled under your agreement with the vendor and covers the instance only. A continuity plan covers your business function, including the people, workarounds and systems outside the platform, so you still need one.

Where should legacy plan data land first?

In a staging table through an import set, never straight into live records. Staging gives you a place to check counts, owners and group names, reject rows that lack an approval state, and rerun the load after fixes without creating duplicates.

For next steps, see ServiceNow Business Continuity Management, data migration and cutover with reconciliation, and import sets for data migration.