Migrating off a legacy system
How do we move off an old system without losing our data?
The short answer
TEVEL (תבל) plans legacy migration as a controlled process: first mapping which data and processes live in the current system and what actually needs to move, then defining the new data model, running the migration and validation — and only then moving the work over, gradually. Before replacing anything, it also checks whether replacement is needed at all, or whether the existing system can be extended or wrapped with a new layer.
Before replacing — understand what isn't working
Switching systems is a big decision. Sometimes the real problem is missing integrations, poor UX or a broken workflow — and an integration layer or complementary module on top of the existing system solves it with less risk. When the system genuinely can't support the growth or the process, a migration is planned.
What a controlled migration includes
- Mapping the data, fields and processes in the current system
- Deciding what moves, what is archived and what gets cleaned up
- Field mapping to the new model and de-duplication
- Trial runs and reconciliation against the source
- A transition period with a clear rule for where work happens
- Training and gradual rollout
Why adoption matters as much as data
A migration succeeds when people actually work in the new system. That's why UX, training and post-launch improvement are part of the plan — not an afterthought.
More questions
Can data be extracted from any old system?+
In many cases yes — via exports, APIs or database access — subject to the existing system's capabilities and permissions. This is checked during discovery.
Do we have to replace the whole system at once?+
No. It's often better to move in stages, module by module, or keep part of the existing system and integrate with it.
How long does a migration take?+
It depends on data volume, the number of systems and process complexity — which is why estimates come after discovery.