An older system: what to keep and what to change first

Identify the reason for change

An older system may still carry out an important task reliably. Age alone is not enough to justify replacement. The reason might be difficult changes, missing integrations, unsupported technology or a workflow that has changed since the application was designed.

These problems call for different solutions. A new user interface may not remove data errors. Rewriting an application may not clarify approval rules. In the initial assessment, distinguish process, data and technical issues and define how you will know the situation has improved.

Map the less obvious dependencies too

Applications are often connected to exports, scheduled tasks and team habits that the documentation does not capture. Talking to people in operations may reveal a report needed to close the month or a file that another department processes. A replacement needs to retain it or provide an agreed alternative.

Start with an inventory of functions, interfaces, data and access. Check licences and the availability of source code too. The initial step may produce a list of missing information. That also helps establish a realistic scope and estimate.

Choose a part you can separate

Gradual replacement makes sense when you can separate a selected function and direct it to a new solution while the rest stays in the original system. This approach needs a clear boundary and a way to share data. Not every system supports it without substantial changes.

A portal, integration layer or standalone module can be a first step. Choose a part that delivers a useful result while helping validate the technical approach. Keep the scope focused so that the first step does not quietly become a complete replacement.

Migration needs a rehearsal and a rollback procedure

Test data migration on a suitable copy and compare the results. Check relationships between records, missing values and differences in what old and new fields mean. A successful import without these checks does not yet establish that the team can continue its work.

For a critical change, define the deployment window, the person making the decision and the conditions for rollback. Account for data that may be created during the change. The rollback plan must explain what happens to it; restoring an older backup alone may lose new records.

Example decision: a new partner portal

A business may need a partner portal while its internal system continues to process orders. One option is to extend the original application. Another is a new, connected portal. The comparison should cover available interfaces, account management, data freshness and responsibility for fixing failed transfers.

If the integration boundary works, the portal can be a separate phase. But if the data cannot be reliably separated, a new frontend simply covers the original problem. This is an illustrative situation; the suitable approach follows an assessment of the particular application and its processes.

Agree on what happens after the first change

A new module may run alongside the original system for a while. That period needs clear operational responsibility: who monitors the connection, fixes errors and decides on further replacement. Without a plan, a temporary architecture can easily become permanent.

When planning, compare the cost of running both systems and the team's ability to maintain the solution. Gradual change should be a deliberate decision with defined phases. After each phase, reassess the next scope based on the results and new information about the system.

Put the topic into practice.

Related project: FaxCopy a.s.