System Migration Plan Template
Four documents and four sheets that size the freeze window from the target platform's own import ceilings before anyone agrees a date.
Free download · No account needed
Migration Plan
1. The window, computed
The business has agreed a freeze of hours, from to , with as the first hour of real use.
Three inputs decide whether it can hold the load, and all three are knowable weeks out.
| Record counts per object | from the source, on the reconciliation’s own scope filter |
| Published ingest ceilings | rows per file, rows per rolling day, concurrency, the API path |
| Measured throughput | one large file loaded end to end, including post-upload processing |
The critical path
| Phase | Objects | Rows | Files | Hours |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 |
A phase is not a team
A child object cannot load before the parent it references exists in the target, because the reference is resolved by lookup at load time. Only objects inside one phase run together, and the concurrency ceiling caps even that.
2. The decision that number forces
Filled in once the phase table has a total. If the critical path exceeds the window, name the object carrying most of it before proposing anything else.
Every cutover plan you can download is a task table: task, dependency, team, owner, planned start, status. The dependency column is free text and the window length is a number somebody chose. So the two facts that decide whether the plan is possible get discovered in a rehearsal that costs a weekend, or at three in the morning on the Saturday. Both are arithmetic. Record counts per object, the target platform's published ingest ceilings, and the dependency order among the objects give you a critical path in hours.
Norwood Filtration had a 36 hour freeze and 22,377,200 rows across six objects. Its target caps one import at 1,048,576 rows, the whole day at 10,000,000, and concurrency at two large loads whatever the size of the team. Phased on real references that is 55.28 hours, and activity history is 51.94 of them. It is 96.5% of the rows and none of the configuration, which is why it never came up in a design session. Loading it after go-live leaves 3.34 hours.
The second half is the gate. Counts reconciled at 100.0% on all six objects while pipeline was short by 1,438,760 dollars, because 2,140 opportunities held in euros, pounds and Canadian dollars loaded at face value in the corporate currency. A two-pass field mapping shows why: the currency column had no target row. So every object reconciles on a count, a sum and a completeness rate.
What's in the pack
Load Order
Records, files, dependency, phase and hours per object, with the phase makespan computed from the concurrency lanes rather than summed.
Field Mapping
A row per source column including the ones with no target, each carrying its failure mode and the post-load check that would catch it.
Data Validation
Count, sum and field completeness per object, each with its scope filter, because a variance only means something when both sides used the same one.
Issue Log
One row per event with the runbook row it happened on, and a Found By column that tells the next cutover which gate earned its place.
Migration Plan
The window arithmetic, the scope with its deliberate exclusions, the gate thresholds and who signs each one, and the roles for the window.
Cutover Runbook
Every step with an id, an owner and a predecessor, a gate after every load rather than one at the end, and the buffer sitting before the go decision. A live sync that fails after go-live gets reconciled separately.
Rollback Plan
The three windows rollback means different things in, what each one costs in hours and re-entered records, and the row where it becomes a merge.
Comms Plan
Every message with a send time and a drafted body, including the fallback announcement nobody writes in advance and the all-clear that names what is missing.
How to use it
- 1
Open in River, or take it blank
Open the pack in River and hand it your counts and field export, or download the Word documents and CSV sheets and do the arithmetic yourself.
- 2
Send three things
Record counts per object with the in-scope filter, the target platform and edition, and the source system's field export. A measured load rate too, if a rehearsal produced one.
- 3
Size the window before anything else
The ceilings and the dependency graph turn the counts into a critical path in hours. If it exceeds the window, the object carrying most of it gets named first.
- 4
Set the gates, then run them
Every object gets a count, a sum and a completeness rate with a named signer. Failures land in the Issue Log with a records-affected count, an owner and a date.
Frequently asked questions
Is this template free?
Yes. The zip is Word documents and CSV sheets, no account and no card. Edit with AI reads your counts and field export, computes the window and fills the sheets. Only need the Comms Plan, timed against a runbook you already have? A standalone tool builds just that. Everything else sits in the template library.
What format are the downloaded files?
Word (.docx) for the four documents, CSV (.csv) for the four sheets, zipped together. Excel, Numbers and Google Sheets open the sheets straight off the download, and the plan and runbook open in Word or Pages. There is nothing to convert.
Does it work for a target platform other than a CRM?
Yes. The arithmetic needs a per-object record count, published ingest ceilings and a dependency graph, and an ERP, a helpdesk or a billing system all have those. Designing the target's object model is separate work, covered by the CRM implementation plan. This pack assumes the target already exists.
What if I have no measured load rate yet?
The window gets computed on a stated assumption and re-run once a rate exists, which is the honest version. Everything else holds: the file counts, the dependency phases and the rolling-daily-ceiling floor are all read off documents rather than measured, and the floor alone often settles the question.
Why does the validation sheet ask for a sum as well as a count?
Because the load failures that lose data mostly complete. An unmapped column imports empty, an unrecognised picklist value imports blank, and an amount whose currency never mapped imports at face value. All three reconcile at 100.0% on a count, and only a sum finds the third.
The source data is a mess. Should I clean it first?
Clean before the freeze or not at all, and size it before committing. Cleaning inside a window is unreviewed data entry by a tired person, which is why the pack quarantines rejected rows instead. A scoped CRM audit prices that work first.
What does 'Edit with AI' actually do?
It signs you up, installs this pack as a private workspace, and puts the agent in front of the sheets with nothing in them. Then you send the counts, the field export and the target edition, and the first thing it returns is hours needed against hours agreed.
Find out whether your freeze window can hold the load
Take the Word documents and CSV sheets blank, or open this exact pack in River and get the critical path in hours first.
Edit with AI