Replacing AS/400: cleanly replace instead of integrating forever

An AS/400 (IBM i) can be connected to Business Central, but that only prolongs the dependency. The more honest path is to replace, not integrate. The real challenge is not the interfaces, but the data grown over decades, often undocumented, and the business logic that no one fully knows anymore.

Why replace rather than integrate?

Keeping an AS/400 as a permanent back end behind BC preserves exactly the system you wanted to replace, along with its maintenance risk and dwindling know-how. Integration is at best a bridge for a period and never a goal, even if it feels like one inside the project.

Every interface you build today is a dependency you have to maintain tomorrow. And it will be maintained by people who still understand the legacy platform, which over the coming years is the scarcest resource in this field.

The honest way to handle it is a decision about a date: if a bridge is necessary, it belongs with a switch-off date and an owner who defends that date. Without a date the bridge becomes a permanent state, and that costs more than the replacement would have, because you then operate and maintain two systems instead of switching one off.

Why is the data the core problem?

Applications grown in RPG or COBOL carry logic in fields whose meaning exists only verbally. Data structures without documentation, exceptions without a recorded rule, fields that have been used for something else for years. The technical loading is manageable and well supported; reconstructing that meaning is the underestimated block, and it needs experienced people rather than additional tools.

• First map the data and processes that are actually used, not the assumed ones.
• Then reconstruct meaning and define rules, before mapping.
• Map, validate and load in test runs with real data, not with sample data.
• Not everything belongs in the live system: decades of history are separated. What daily business needs goes live, the rest into a clean archive.

Source: Microsoft Learn: Set up company configuration packages

How big is the effort, honestly?

Whoever skips the reconstruction of undocumented legacy logic migrates blind spots into a new system. The effort for it cannot be derived from the volume of data but exclusively from the documentation state of the legacy application, and with AS/400 landscapes that is regularly the worst part of the project.

With real complexity, experience decides which exceptions are still lived and which have long been dead. That single distinction saves more effort than any tool deployed, because every dead exception carried along costs mapping, testing and later operation, and afterwards nobody dares remove it from the system again.

Control stays on your side, with Business Central as home. Before you build an interface you will never be rid of: let us look at your AS/400 data and show the honest route to replacement.