PIPELINEGuide
Data migration: examples from practice
How data migration is actually used in the day-to-day of small businesses — concrete processes instead of product promises, including cases where it didn't work.
In practice, data migration almost always starts with exactly one process, not with an overall concept. The effort of migration lies almost entirely in data quality — not in transferring. Expansion only happens when the first step demonstrably works in real operations.
01 — Practice
What this looks like in concrete terms
The effort of migration lies almost entirely in data quality — not in transferring.
A typical start looks like this: the business names the one process that causes the most trouble. A report on the actual state. It's regularly uncomfortable and always useful.
After go-live, expansion doesn't happen immediately — observation does. Migration with count log and defined fallback option.
02 — 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.
03 — Scope
When we advise against it
- The process is still changing. As long as you're adjusting the process itself, manual work is more flexible and cheaper.
- Exceptions outweigh standard cases. Then you're automating exceptions, and that gets expensive.
- There's no data foundation. Without digitally available source data, the basis is missing.
- Volume is too low. With five transactions a month, no system pays off — not even an affordable one.
- The real bottleneck lies elsewhere. If you don't have enough inquiries, you don't need faster processing.
04 — Questions
Frequently asked questions
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.
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.
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.
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.
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.
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.