PIPELINEGuide
Do data migration yourself or have it done?
Much of what surrounds data migration can be built in-house — the question is whether it pays off. When internal effort makes sense, where the line is, and which route is the most expensive.
Building data migration yourself pays off when the project stays small, someone in the business has time for it, and no one depends on it running on a specific date. As soon as other systems need to be involved or someone is liable if it fails, external implementation is usually cheaper — the most expensive route is the half-finished one.
01 — In-house effort
Build yourself or have it built?
- Building yourself makes sense when someone in the business has the time and interest, the project stays small, and no one depends on it being live by a specific date.
- Ready-made platforms get you to a first result quickly, but hit limits where custom processes, custom data, or integrations with existing systems come into play.
- Having it done pays off as soon as data migration needs to communicate with other systems, as soon as someone is liable if it doesn't work, or as soon as internal effort becomes more expensive than external implementation.
- The most expensive path is the halfway one: built in-house for months on the side, then abandoned and rebuilt externally. If you decide on in-house effort, set a time budget and an abort point.
- Hybrid model: concept and setup external, maintenance internal. This is often the most economical route for data migration — provided the handover is documented.
02 — 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.
03 — Calculation
How to calculate it
Four numbers are enough: How often does the process occur? How long does it take? What does an hour cost internally? And what does the solution cost — one-time plus operation over three years?
An example: A process that occurs twice a week and takes 40 minutes each time ties up around 69 hours per year. At an internal hourly rate of 45 euros, that's roughly 3,100 euros per year locked in there. If a solution reduces this effort by two-thirds, it often pays for itself — depending on the actual quote — within one to two years. We'll give you the exact figure for your case after the initial meeting.
This calculation is deliberately conservative: it only accounts for the time saved, not the errors avoided or the orders that come through due to faster response. In practice, the benefit is usually higher — but you shouldn't count on it before you've measured it.
04 — Questions
Frequently asked questions
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.
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.
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.
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.
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.
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.
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.
05 — Decision
How to move forward
The most affordable next step is a conversation, not a quote. Twenty minutes is usually enough to clarify whether a project makes sense, what scope it involves, and whether we're the right fit.
If we're not, we'll say so. An honest no costs less than a project you abandon after three months — for both sides.
06 — Next
Related pages
Next step
We'll look at your starting position.
Tell us what's eating up time today. That becomes an assessment with effort and benefit — and only then an offer.