← All Kits · All Guides · Data Migration Series

Ask the Right Questions First

The list I run through before agreeing to anything · Part of the Analyst Prep Kit

Most migration trouble traces back to a question nobody asked in week one. This is the list I run through before agreeing to a date, grouped by what each answer protects you from.

The short version. Five questions decide the project: what success is, who signs, who decides, what happens if it goes wrong, and what happens to work created during the gap.

What does success look like?

Before reading on, try answering it for a project you are on now. Harder than it sounds, isn't it.

Push until it is countable. "All active clients available on day one, visit history back to 2019, documents attached to the right client, no client appearing twice." Every one of those is checkable, which means every one becomes a line in reconciliation.

Then ask the other half: what does failure look like? People answer that one faster and more honestly, and the answer tells you what they are actually protecting.

Who signed the contract?

This is not the same person as your daily contact, and you need to know both.

The signer owns the outcome and the budget. They are who you copy on gate emails and who you turn to when the project stalls, and knowing who they are before you need them is the whole point. Asking for the first time during a crisis is expensive.

Who decides on data questions?

Different from both of the above. You need a named person who can say "yes, those two records are the same person" and "yes, that status maps to Active", and whose answer is final.

Ask what their availability actually is. An expert who is available two days a week is a schedule constraint, and it belongs on the plan as a named risk rather than as a surprise in week five.

Also ask for one point of contact for everything else. You are not there to manage their address book. One person receives, one person forwards.

What is the recovery plan?

Ask it plainly: if this goes wrong, what do we do? The answer needs three parts.

What we go back to. Usually the old system, which is why it goes read only rather than being switched off, and why the date it is decommissioned matters.

Who decides to go back. A named person and a threshold. "If reconciliation does not pass by Tuesday, we postpone" is a decision made calmly in advance.

What we keep. The final export, the load files, the crosswalk of old ID to new ID. Keep them for the whole contract, not just until go-live.

What happens to work created during the migration?

The question almost nobody asks up front, and the one the client's staff feel every day of the project.

A migration takes weeks. The business keeps running. Settle the freeze date, what read only means, and where new work goes instead. The cutover article covers the bridge sheet that answers it.

The rest of the list

QuestionWhat the answer protects you from
What is not migrating?The dispute in month three
How much history is there, really?A timeline built on an estimate
Is any of it on paper?A scanning workstream discovered late
Who has read access to the source, and when?Two weeks of waiting for credentials
What are the privacy rules on this data?Handling health or financial data carelessly
Who tests, and do they have the time booked?UAT that never happens
When is the old system decommissioned?Losing your fallback without warning
What holidays and busy periods fall in the window?A gate that cannot close for two weeks
When does the contract end?Discovering the deadline at the same time as the client

How to ask without sounding like an interrogation

Frame every question against their goal. "So that everyone is live before your audit in October, I need to know who can decide on data questions and how often they are available." The question is the same and it now belongs to them.

Write every answer into the same follow up email, with next actions and dates. Naming the action, the person and the day is not just tidy. It is the pattern Gollwitzer and Sheeran found produced a medium to large improvement in whether an intention became a completed action, across ninety four tests.

The one habit

Ask what failure looks like. It is the fastest way to find out what the project is really about.

What question do you always ask at the start, that other people seem to skip?

Up next

Previously: Stage 8: Hypercare and Close  ·  All eight stages

The checking work is SQL, and it is not advanced SQL.

Counting rows, grouping to find duplicates, and joining to find orphans covers most of what a migration asks of you. The SQL Kit teaches those moves in order, with the data in front of you.

Open the SQL Kit →

Or start typing straight away: open SQL Drill, thirteen queries that each add one thing to the last.

The whole run, in one place.

You are moving a client’s records into a new system, and the part that worries you is the week the client goes quiet. The Data Migration Playbook is all eight stages in order, 63 pages, from the first kickoff meeting through hypercare, so you can run one without finding the important question three weeks too late.

The Data Migration Playbook, $29 →

References

  1. Gollwitzer, P. M., & Sheeran, P. (2006). Implementation intentions and goal achievement: A meta-analysis of effects and processes. Advances in Experimental Social Psychology, 38, 69–119.
  2. Haller, K., Matthes, F., & Schulz, C. (2012). A detailed process model for large scale data migration projects. Business Information Systems (BIS 2012), Lecture Notes in Business Information Processing, 117. Springer.