A few weeks ago I saw something I had to look up before I understood what it was. In a data dump from an ERP system there was a field called Telex. Not "fax", but actually Telex. The kind of communication you used before the fax even existed.
We had to blink three times because it so painfully illustrates where many companies are right now. AI is the future. Everyone feels it. Everyone wants to accelerate with it. But to use AI effectively, you first have to go all the way back to the past. To your legacy systems. To your old ERP. To databases built in an era when nobody ever imagined you'd want to sync data in real time to a cloud platform, a time when you tried to keep your database small by using fewer decimal places.
That's the paradox facing many SMEs and mid-market companies in Europe. They want to move forward, but part of their software is still stuck in the stone age—or well...
What we practically always see is that somewhere there's one major bottleneck in the organization. The system that was once the backbone, but now holds things back. It could be a SAP environment that's not yet cloud-ready. An Oracle database that has grown shut over the years with customizations. Or another legacy ERP with outdated data types, limited precision and data structures that only make sense if you rewind twenty years.
And then the familiar pattern begins. There's a modern cloud ambition. There are AI plans. Teams build dashboards, automate reports, start pilots. But every route ultimately comes back to the same core question: how do we bring that old system along.
Many organizations go for the easy route first. Integration platforms promise exactly this. Tools like Make, Workato, n8n or MuleSoft give you a low-code way to connect systems. Fantastic for many use cases and it looks polished. But as soon as you really want to do an ERP migration—not just sharing data but moving data—they hit their limits.
Because then it's no longer about a few API calls. It's about large volumes. Complex transformations. Many exceptions. Performance suddenly becomes decisive. Error handling needs to be rock solid. And low-code tooling usually isn't built for that. Those platforms are strong for the integration afterward. But for the first real migration push, they're often simply not performant enough.
Then comes step two. The "let's do it manually" route. Exports. Cleaning up tables. Consultants mapping fields. Running a first migration and hoping it's correct.
But an ERP migration is almost never done in one go. You do a first run. You discover that certain records need to be interpreted differently. A mapping turns out not quite right. The business wants an extra field after all. Or a process needs to work slightly differently. And then you get to start over. Sometimes twice, sometimes five times. Each iteration costs extra time, extra money and above all extra risk. Because you're working through the same mess over and over again.
Full Code for the Win
That's why at Pantalytics we've made a different choice. Many organizations avoid the ERP switch because it's open-heart surgery. But open-heart repairs are necessary. Weak healers make festering wounds.
Bring in the big guns. We go for a full-code solution: containerized Python code in the cloud, with the right AI co-pilot. We refactor the code so we can reuse a lot and stay agile. With that we write ETL and ELT scripts that do exactly what's needed. Extract from the old environment, transform to—in our case—the Odoo model (ODM, love it!). This is in my view truly the winning strategy.
And here's an important advantage. We don't need a perfect dump. You don't have to clean up your data first. Feel free to give us a messy export. With fields like Telex, weird formats and historically grown exceptions. We know Odoo well enough to translate that world into a modern cloud structure. Precisely because Odoo is open source and runs on Python, we can map and validate at lightning speed.
In many projects the migration isn't the endpoint either, but the beginning of a transition period. You want to temporarily run two systems side by side, so you can switch over in a controlled manner—we'll write a separate blog about this. For that we build synchronization modules on top of the migration.
Three Scenarios
You convert the data per business function (in Odoo that's called an App). So for example first your contact list, then your quotes, then your product catalog, etc. There are roughly three scenarios.
The first is keeping legacy as the leading system. Odoo gets populated from the old ERP. A one-way sync toward Odoo.
The second is making Odoo the leading system. The old database becomes read-only and you synchronize one way. Also one-way, but with the cloud as the new source of truth.
The third scenario is where we're currently investing a lot of R&D. Two-way sync. Two systems that temporarily coexist and synchronize daily, or near real-time, with each other. This gives organizations room to transition step by step, without having to overhaul operations in one big leap.
The initial results are very promising. Not just technically, but especially organizationally. It takes the pressure off. Teams can migrate and keep working at the same time. And when everything lands well, the old system can be decommissioned in a controlled manner.
And that's ultimately what it's about. Making AI workable in your business doesn't just mean adding new tools. It also means removing old blockers. Because if your core software can't keep up, neither can your organization.
So the question is actually simple. What is your Telex field? Where is your legacy bottleneck? Which piece of software is still holding your data and AI plans in the past?
If you want to explore that, we'd love to hear from you. Send us a brief sketch of your situation. Even if your dump is messy or you don't yet know which route fits best. Then we'll look together at how to bring your old core into the future. Our telex number is on our website.