PIPELINEGuide
Data migration: contract, ownership and exit
Who owns the data, access credentials, and outputs in the end? The answer to this question says more about a provider than any reference list — and belongs before the signature, not after.
Before commissioning data migration, the following must be clarified in writing: data and access credentials belong to the client, in which format and within which timeframe they will be handed over upon termination, what a later change costs, and that documentation is a quote line item and not a verbal promise.
01 — Contract
What needs to be clarified in writing
- Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
- Handover upon termination. In what format, within what timeframe, at what cost.
- No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
- What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
- Documentation as a deliverable. Not as a promise, but as a line item in the proposal.
02 — Questions
Questions you should ask
- What happens if the project becomes more expensive than estimated — who bears that?
- Who owns data, access, and, if developed, the source code?
- What does operation cost in the second and third year?
- What does the documentation we receive at the end look like?
- How would you measure whether the project was successful?
- Is there a case in which you would advise us against this?
03 — Warning signs
When to be skeptical
- Guaranteed results. Anyone promising top Google ranking or a specific revenue increase is selling something they can't deliver.
- No pushback. A provider who thinks every project is a good idea has either not listened or is only selling.
- Time pressure. Limited-time discounts on project prices are a sales tool, not an offer.
- Unclear ownership. Anyone who won't clearly say who owns data and access doesn't have your interests at heart.
- No contact with technical expertise. If only sales sits in the first meeting, that's where misunderstandings arise.
04 — Questions
Frequently asked questions
Do we need access to both systems simultaneously for the migration?
Yes, at least for the period of trial runs and the actual switchover. After that, access to the legacy system can be restricted or terminated.
How do we ensure nothing gets lost?
Through the count protocol: number of records before and after is compared, samples are checked for content. Only after this acceptance is the migration considered complete.
Do we take everything?
Rarely makes sense. Dead records, test datasets, and ten-year-old transactions burden the new system. We recommend migrating the active inventory and keeping the rest archived and accessible.
What happens to attachments and documents on the record?
They are transferred along, provided the target system supports them. Where the format doesn't fit, it's clarified beforehand whether conversion is necessary or external storage remains more practical.
How long does a migration take?
The transfer itself usually hours. The time goes into analysis, rules, and trial runs — typically two to six weeks, depending on the condition of the legacy data.
What if something is missing after the switchover?
That's why count protocol and fallback option: the legacy inventory remains untouched until acceptance is complete. Subsequent additions of individual areas are possible.
Can we keep working in parallel?
For short transitions yes, with a cutoff date. For longer migrations, you typically continue working in the legacy system until the switchover and transfer the additions at the end.
Next step
Let's talk briefly about whether this makes sense for you.
A twenty-minute conversation is usually enough to clarify whether a project makes sense. If not, we'll say so — that's cheaper for both sides than an offer nobody needs.