PIPELINEGuide
What do you need for a data migration? The prerequisites
Before a data migration even makes sense, a few things must be present in the business. What those are — and which supposed prerequisites actually aren't.
For a data migration, a business needs three things: a specifically named process that currently costs time or orders, existing content or data to work with, and a person authorized to make decisions. Technical knowledge is explicitly not one of them.
01 — Requirements
What you need for a data migration
- A clearly defined trigger. Not “we should do something with AI,” but a process that demonstrably costs time or orders today.
- Existing content or data. Data migration works with what's there. The more complete the starting point, the shorter the setup.
- Access to the systems involved. Whoever manages the credentials needs to be involved from the start — this is, in our experience, the most common cause of delays.
- One decision-making contact person. One, not three.
- Willingness to refine after launch. The first weeks in real operation show what was missing in the concept. That's normal and accounted for.
02 — Participation
What we need from you
- A contact person who can make decisions — not just forward them.
- Access to the affected systems, in time and not on launch day.
- Real examples from daily business — the messier, the more useful for testing.
- Two to four hours for coordination, distributed over the project duration.
- An answer to the question of what success means. Without it, nothing can be assessed afterward.
03 — Fit
When it's worth it
- The process in question occurs at least weekly.
- It follows rules you can write down — even if there are exceptions.
- Today it's manual work that no one enjoys doing.
- There's one person who decides, not three who need to coordinate.
- You can name what would tell you it worked.
04 — Questions
Frequently asked questions
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.
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.
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 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.
05 — Next
Related pages
- Data Migration — Overview
- Data migration — practical examples
- Data migration — measuring success
- Data Migration — Costs
- Data migration — alternatives
- Data migration — how it works
- Data migration — Small businesses
- Data migration — contract and ownership
- CRM integration
- Custom software
- API Interfaces
- All guides
Next step
Initial assessment, no obligation.
Briefly describe what you need. You'll get an honest answer about what's realistic and what it will roughly cost.