A migration plan for a new customer fits on one page: the old system and how the data leaves it, each record type that moves and how many there are, what stays behind, the dates, and the numbers the customer's team signs before you switch them over. It isn't done when the data loads. It's done when they've signed those numbers.
The customer data migration plan template
Fill one sheet for every new customer. Here it is, filled in for a made-up customer.
| Field | What to write | Example |
|---|---|---|
| Customer and go-live | Who they are and the date their team starts working in your product. | A 60-person HVAC contractor, live March 2 |
| Old system and how data leaves it | API, a full export, scheduled reports, files they send, or a login to the old system. Pick from the ways to get data out. | No API; reports from the old system's web portal |
| Source owner | The person on their side with rights to the old system's data. They answer the questions and sign the numbers. | Operations manager |
| Record types and counts | Every type that moves, counted on the old system's own screens at intake. | Customers 3,140 · open jobs 412 · closed jobs since 2023: 9,870 · open invoices 268 |
| What stays behind | What doesn't move, and where the customer can still find it. Decide what moves before you count. | Jobs closed before 2023: kept as a read-only export the customer stores |
| Trial load | A real sample across every record type, and who on their side checks it. | 300 records across all four types; the office manager checks them |
| Acceptance numbers | The count that must arrive for each record type, plus one relationship check and any money totals. | See the acceptance block below |
| Exceptions log | Each record that won't move, by ID, with the reason. Agreed before cutover. | 22 duplicate customers, merged at intake |
| Dates | When the old system freezes, when the full load runs, when you cut over. | Freeze Feb 27 · full load Feb 28 · cutover Mar 2 |
| Go or no-go | Who decides on cutover day, and the rule they decide by. | Source owner and your onboarding lead; any miss not on the log means no-go |
Two fields do most of the work. The first is the source owner: one name on their side who can say what a record means and whether it arrived. NetApp says to be clear on "who has the rights to create, approve, edit, or remove data from the source system, and document that in writing as part of your project plan." The second is the record counts. Every other number on the sheet starts from them.
A customer who sends one clean spreadsheet doesn't need all ten rows. Fill in the first four, agree one count, and load it.
Customer data migration validation: write the numbers before you load
The usual migration check happens after the load: someone opens the new system and asks whether it looks right. Nobody can answer that with a yes or no. So write the acceptance numbers down at intake, before a single record moves.
Three kinds of number are enough:
- A count for each record type that moves. Count after you've agreed what stays behind, so the target is what should arrive, not everything the old system holds. The legacy migration guide shows how to count both sides.
- One relationship number. Records can all arrive and still be wrong. Capsule CRM's migration guide puts it this way: "A single misordered import can orphan every deal in your pipeline, so verify the relationships as well as the row counts." Pick the link the customer would notice first, like jobs that belong to a customer, and count it.
- Money totals to the cent. If your product holds balances, invoices or payments, the open total in the old system is a number the customer already knows. It has to match exactly.
Then the exceptions log. Every record that can't or shouldn't move goes on it by ID with a reason: a duplicate, a test account, a record with no customer attached. Once the customer has agreed to the log, a missing record is one they knew about, not a surprise.
The acceptance block on cutover day
| Record type | Counted at intake | Agreed to leave | Must arrive | Arrived | Match |
|---|---|---|---|---|---|
| Customers | Counted at intake3,140 | Agreed to leave22 | Must arrive3,118 | Arrived3,118 | MatchYes |
| Open jobs | Counted at intake412 | Agreed to leave0 | Must arrive412 | Arrived412 | MatchYes |
| Closed jobs since 2023 | Counted at intake9,870 | Agreed to leave0 | Must arrive9,870 | Arrived9,866 | MatchNo |
| Jobs still linked to their customer | Counted at intake10,282 | Agreed to leave0 | Must arrive10,282 | Arrived10,278 | MatchNo |
| Open invoice total | Counted at intake$184,212.40 | Agreed to leave$0.00 | Must arrive$184,212.40 | Arrived$184,212.40 | MatchYes |
Nobody has to make a judgment call here. It's a no-go until someone finds those four jobs or the customer adds them to the log.
Customer data migration best practices: who signs what, and when
The order is the usual one: a sample load, then the cutover date. What the plan adds is a name on each step.
Five gates, and who signs each one
First, the source owner signs the sheet at intake. Second, the customer's admin checks the trial load. Third, your team runs the full load. Fourth, the source owner signs the reconciliation against the acceptance numbers. Fifth, both sides call go or no-go and you cut over.
Your team produces the reconciliation. The person who signed the sheet signs it. When someone new turns up at gate 4 with new expectations, the counts signed at intake are what you go back to.
Write the go or no-go rule into the sheet before cutover night. Redwerk, a software firm, says a good cutover runbook has "a go/no-go checkpoint whose pass criteria come straight from validation." The acceptance block is your pass criteria, and the two people who call it are already named on the sheet.
The gates also show you what you're waiting on. A trial load stuck for a week because their admin hasn't looked at it is a people problem, not a data problem. Chase the admin.
Customer data migration mapping: what you write once and what changes per customer
When people say data migration strategy, they usually mean moving everything at once or in phases. For a team that onboards customers every month, the strategy is the part that doesn't change between customers: the blank sheet, the gates, the kinds of acceptance number and the rule for exceptions. Write that once. The plan is the sheet you fill for each customer.
Mapping fields and getting data out both depend on the old system. Each system has its own fields and its own way of letting data out, and two customers on the same system can use it differently. Check the data mapping against each new customer's records before the trial load.
Keep every filled sheet. The counts won't carry over, but the record types, the list of what stays behind and the exceptions usually do. The next customer leaving the same system starts with a sheet that already lists most of their questions.
Running the plan without engineering resources
Rubie starts with the part of this plan that's usually slowest: getting accurate counts out of a system the customer doesn't know how to export from.
Curbwaste's implementation team feeds customer files into Rubie before the first call. That gives them specific questions about data quality and lets them send useful feedback in the first week, instead of finding problems after several calls and sample uploads.
From there, Rubie gets the records out of the old system, even with no API or clean export, and loads them into your product. Every record your onboarding team approves, rejects or edits in Rubie's review queue lands in an audit trail, so the reconciliation the customer signs has a record behind each number. No engineering time, no consultants, no new headcount. See how a Migration Playbook runs.
