RETHINK MIGRATION.

Migration is expensive, slow and risky. Because that is how it is sold.

Almost the entire market migrates with the same two providers in the background. That keeps prices high, projects long and you on a NAV release that fell out of support years ago. We rebuilt migration as a product instead of a consulting project – and without the detour through intermediate versions. Your data moves to Business Central in the background while you keep working. The go-live takes a lunch break.

4 weeks to go-live · switch-over without downtime · data migration at a fixed price, the whole project on request

Check your direct migration route Talk to a migration specialist

RETHINK MIGRATION. Our campaign film. Watch it to the end.

Two oceans. One destination. 14,000 miles.

Until 1914 there was no shortcut between the Atlantic and the Pacific. A freighter from New York to San Francisco ran the entire length of South America, around Cape Horn and back up the other side: roughly 14,000 miles through one of the most feared passages in seafaring.

The destination was never the problem. The established route to it was.

Schematic. Distances for the New York–San Francisco route.

On 15 August 1914 the freighter Ancon became the first ship to pass through the Panama Canal. The same route now measured roughly 6,000 miles. The ships had not become faster, the crews were not working harder, the destination had not moved. Only the detour had disappeared.

Your migration has a Cape Horn too.

Anyone moving an old Navision installation to Business Central today is usually offered a route that runs roughly like this: first to a newer NAV release, then to the next one, then to Business Central v14 as the last version with the old programming model, onwards from there – and only after all that to the release you actually want to work on.

NAV 2009 is an example here. Which intermediate stages can be dropped in your case depends on release, customisations and target architecture.

Every stop is a technical state of its own: build it, test it, document it, leave it behind. This chain is not a trick. For years it was the technically obvious route, and project methods, costing models and proposal templates grew up around it.

Only technology changes faster than methodology. An established process is not automatically a technically necessary one.

The usual question is: how do we work through this chain as efficiently as possible? The better question is: do we still need it at all?

The truth about migrations

Ask ten Microsoft partners to quote your NAV migration and you will get ten quotes. What you will not get is ten real alternatives.

Because a large part of the market tends to have the actual migration carried out as a white-label service. Two companies dominate practically the entire migration market from the background. They deliver the work for Microsoft partners without ever appearing in front of the end customer: the project runs under your partner’s name. Your partner adds their margin on top and delivers. And those who do not work with them tend to recommend starting from scratch, usually because the capacity or the experience for a migration project simply is not there in house.

Division of labour is normal, there is nothing wrong with that. What is wrong is the impression it creates: that you have a choice. What you are actually comparing are proposals, not methods. The engine underneath is the same, and so are its limits, its timelines and its prices.

That is the real reason so many companies are still stuck on old NAV and BC releases today. Not convenience. Not a lack of insight. A market that charges six figures to solve a problem it created itself. For a business with 40 employees that is no longer an investment decision, it is a reason not to start at all.

That is exactly what we are changing. We make migrations affordable for mid-sized companies again, and we say openly how this industry works.

The upgrade trap

Most companies did not stay on an old ERP release by choice. They were built into it.

Year after year, more custom code piled up. With every customisation the next upgrade became more complex, riskier and more expensive. At some point standing still was simply the more economical option.

First you pay for that complexity to be created. Later you are asked to pay a second time for it to be taken away again.

And when that time comes, every intermediate stop carries a small project of its own:

An environment has to be built, run and torn down again.
Data has to be transferred and checked for completeness.
Customisations have to be made to run – on a state nobody will ever work on productively.
Departments have to test what they will leave behind shortly afterwards.
Errors introduced here travel on to the next stop.
Every transition extends the timeline – and with it the window in which requirements, people and priorities change.

That does not mean intermediate stages are always wrong. There are cases in which an intermediate step is the safer route. It should just be a technical necessity, not a default setting.

And now you want to hand your upgrade back to the very people under whose watch your ERP became an upgrade trap in the first place?

Where else in your life would you decide like that?

This is not a law of nature and not a purely technical problem. It is the result of decisions that ERP vendors and consultancies recommended, implemented and invoiced over many years. It is exactly this project logic that turns migrations into a gold mine. We break with it.

For us a migration is a bridge. Destination, route, date and price are fixed. You are not paying for additional project days, you are paying for a safe arrival in the new system.

That does not make us popular everywhere in this industry. Whoever earns money on long projects takes little joy in short migrations.

Our customers do.

What the software does – and what it does not

DataMigrate Pro is built to read, analyse and prepare data and structures from old Navision and Dynamics NAV installations for Business Central, without the detour through intermediate versions: tables, fields, relationships, posted documents, historical records, custom tables.

What is automated is the repeatable part. Reading out, mapping structures onto the target model, transforming, running again after corrections, keeping the old and the new system aligned. A migration run is not a one-off event here, it is a process you can repeat until the result is right.

What is not automated is everything that calls for a decision:

The software handles	People decide
Reading structures and mapping them onto the target model	Which customisation is still needed in practice
Transforming data and running it repeatedly	What moves into the standard and what stays an extension
Keeping the old and the new system in sync	Which data quality gets cleaned up instead of carried over
Checking completeness technically and logging it	Whether a business process still holds in the target system
Carrying changes across until the cut-off date	When to switch over

The division of labour is the point. Tools are good at repetition, people are good at decisions. A migration project in which people repeat and tools decide is set up the wrong way round.

No big bang. A lunch break is enough.

The standard route has a cut-off date. The legacy system goes off on Friday evening, the data runs over the weekend, and on Monday morning you find out whether it worked. Either it runs or it does not. That single moment is why migrations get postponed by years.

We removed the cut-off date

DataMigrate Pro transfers your data continuously in the background, live or on a fixed schedule, from NAV to Business Central, while people keep working in both systems. Both systems stay usable until the agreed date, and on switch-over day the data is long since across.

What remains is the final sync, and it takes no longer than a lunch break. That refers to the switch itself, not to the whole project: the preparation takes a few weeks, the switch-over takes a lunch break. After that your team carries on working in Business Central.

Direct does not mean unchecked

The Panama Canal did not make navigation unnecessary. It made the detour unnecessary.

Analysis, mapping, test migration, validation by your own people and sign-off all remain. We remove technical intermediate stops, not the controls. And because the legacy system stays productive until the cut-off date, there is a way back until the last moment.

Everything else you would expect is here too. We convert your existing code into new AL extensions, in consultation with you, plus licences, consulting and support, after the switch as well. The difference is not what we offer. It is how the go-live works.

Have you ever heard of a go-live like that? Probably not. We know of no other provider who works this way.

Go deeper: NAV to BC migration with DataMigrate Pro · ERP migration from other systems to Business Central · Copy companies with CloneMyCompany · Business Central licences from the Microsoft partner

Comparison

The long route and the direct one, side by side

Not: a lot of work here, none there. Rather: which work comes out of your destination – and which only out of the route to it.

Aspect	Direct migration with DataMigrate Pro	Classic upgrade route via intermediate versions
Route to the target How many technical states lie between the source and the target system.	✓ Straight to Business Central, where technically sound	✕ Usually several intermediate versions
Technical states How many environments are built, run and left behind.	✓ Source system and target system	✕ Plus every intermediate stage
Testing effort for departments How often the same processes have to be checked.	✓ One target state is tested and signed off	✕ Every intermediate stage wants checking
Switch-over How the move from the old to the new system works.	✓ Continuous sync, controlled cut-off date	⚠ One date, one weekend, one attempt
Operations during the project Whether people can keep working in the legacy system.	✓ Both systems stay usable until the cut-off date	⚠ Downtime over the switch-over weekend
Work that happens either way What the direct route does not shorten either.	⚠ Analysis, mapping, testing, validation, sign-off	⚠ Analysis, mapping, testing, validation, sign-off

The strength is not that work disappears

Analysis, testing and sign-off remain. What falls away is the work that would only have been created by the upgrade chain.

Complexity is not a mark of quality

If a proposal plans several intermediate stages, you should be told for each one why it is technically necessary.

Evidence

Three projects, three starting releases

Designwerk, Volvo Group

Business Central v14 to v28, on-premises

Moving a productive environment, including converting the custom code from C/AL to AL.

Starting point: Business Central v14
Target: Business Central v28 on-premises
Special feature: code conversion included
Result: no downtime for the production line

Read the case study

Gaming industry, North America

NAV 2013 R2 to Business Central Cloud

A fully remote project with delta synchronisation.

Starting point: Dynamics NAV 2013 R2
Target: Business Central Cloud
Technical migration: two weeks
Result: cost roughly two thirds below the competing quotes

Read the case study

Vita Tahedl

NAV 2009 to the cloud

Migration from a release more than fifteen years old, with no intermediate step.

Starting point: Dynamics NAV 2009
Target: Business Central Cloud
Whole changeover: under six months
Result: completed during ongoing operations

Read the case study

Cedrik Ferner

Business Central book author & Senior Consultant · mybusinesscentral.de

From the corner shop to the enterprise

We do not pick our customers. Large partners often do, and they pick by revenue. Anyone too small does not get a no, they get a place far back in the queue.

The same foundation sits under every project: DataMigrate Pro. What differs are the go-live scenarios. The larger the organisation, the more people, sites and dependencies are involved. The method stays the same.

That works because we treat migrations as what they are at heart: technical projects. Numbers, tables, relationships. Our name says as much. The IO in IO Integrated stands for input/output. We are data people.

Whether the direct route holds in your case is therefore not decided by the size of your company, but by concrete things:

Starting release and technical condition of the database
Scope and nature of the customisations
Add-ons and third-party solutions in the legacy system
Data quality and depth of history
Target architecture: cloud, on-premises or mixed
Requirements for auditability and retention

The three projects above are individual reference cases, not a guarantee. What is possible in your case is what the upgrade check tells you. And if the analysis shows that an intermediate step is the safer route, we will say so.

Let us find out whether you need the detour.

In the upgrade check we look at your starting release, your database, your customisations and your target architecture, and tell you whether a direct migration is technically sound. After that you know which route is realistic for you – regardless of who you end up taking it with.

Check your direct migration route Talk to a migration specialist

Free and without obligation

A clear answer on technical feasibility

We usually reply within one business day