If your team copies approved work from one system into another, replacing either application may leave the underlying problem untouched. Equally, connecting them may preserve software that cannot support the business much longer.
The useful decision is what to keep, what to connect, what to modernise in parts and what to replace. Start with the work the system must support, its condition and the information you can reliably get in and out.
Age alone does not tell you what needs changing
An older application can still fit its job. A recently purchased one can already force staff into workarounds.
Government guidance identifies several reasons technology becomes legacy: support ending, updates becoming impossible, running costs becoming unjustifiable or risk exceeding an organisation's tolerance. It does not define the problem by a birthday. Those are useful questions for a business too, although the guidance was written for government. Managing legacy technology, GOV.UK.
Describe the operational problem before choosing a technical response. "Staff retype approved orders into accounts" identifies a handoff to investigate. "We need a new system" has already selected an answer.
Check whether the task itself is needed. An unused report might be retired; an approval that protects payment accuracy needs different treatment. Remove unnecessary work deliberately, with the person accountable for the process.
Keep four options open
Modernisation is often used as an umbrella term for all these changes. Here, "modernise in parts" means changing a specific capability while retaining the rest.
| Option | When it deserves consideration | What could rule it out |
|---|---|---|
| Keep and improve | The software fits the work, remains maintainable and has acceptable risk. Configuration, training or a process change could address the problem. | The problem sits in a core limitation that those changes cannot remove. |
| Connect | Useful systems hold the right records, but people repeatedly move information between them. A permitted, supportable exchange is available. | Required records or operations are inaccessible, or the receiving process cannot use them reliably. |
| Modernise in parts | A specific capability causes difficulty and can be changed separately. The retained system can continue operating during the work. | Dependencies prevent a workable separation, or the old system must be retired too quickly. |
| Replace | Core functions no longer fit, or support and risk problems cannot be adequately addressed while retaining the system. | A candidate replacement has not demonstrated the required work, data transfer and recovery arrangements. |
A business can make different choices for different functions. It might keep its accounts package, connect order records and replace a poorly supported scheduling application. The decision should explain each boundary.
Gather evidence before accepting a proposal
Ask the people who use the system to walk through ordinary work and exceptions. Include whoever maintains it, the process owner and the supplier where needed. Collect evidence in five areas.
Business fit. Which jobs does it handle well? Where do staff leave the application, correct records or ask someone else for help? Identify the consequence of failure: an inconvenient report and an incorrect payment deserve different controls.
Support and maintenance. Record the exact product, version, hosting arrangement and support terms. Find out who can diagnose faults, apply changes and restore the service. Access to source code is useful only alongside the knowledge, dependencies and rights needed to maintain it.
For unsupported products, temporary precautions do not remove the underlying exposure. The NCSC recommends moving away from obsolete products; its interim measures reduce risk rather than provide a risk-free way to retain them. Connecting an unsupported application does not restore security updates. NCSC guidance on obsolete products.
Data and ownership. Inspect representative records. Can you identify duplicates, missing fields and conflicting values? Decide which system owns each important field. The customer record might belong in one application while the approved credit limit belongs in another.
Access and constraints. Confirm the available interfaces, permissions, licence conditions, usage limits and data export arrangements. Include connected systems and reports that rely on the application. A supplier saying "we have an API" is a starting point, not evidence that your particular task is possible.
Cost and disruption. Compare running costs, manual handling, change work, data cleaning, testing, staff training and ongoing support. Include temporary arrangements and eventual retirement. Request the assumptions behind each estimate. There is no useful universal price ranking between a small connection and a replacement whose scope has not been established.
Prove the connection with the records you need
An application programming interface, or API, lets software exchange requests and data. The important question is which requests it permits. A connector might read customers but be unable to update the approval status your process needs.
Use a realistic example to check the actual information and operations available. The Government Digital Service recommends checking both when considering an interface to an older system. Its guidance also warns against simply recreating an existing process in new software. Moving away from legacy systems, GOV.UK.
A supported file export and import may be sufficient for a scheduled batch. It needs checks for file completeness, record identifiers, corrections and rejected rows. Real-time transfer is worth specifying only where the work needs it.
Some applications send event notifications, commonly called webhooks. Their delivery rules matter. Stripe, for example, documents automatic retries, possible duplicate events and no guarantee of event order. Check the equivalent documentation for the product you use; do not assume every provider behaves identically. Stripe webhook documentation.
Where no suitable interface exists, a permitted interaction with the user interface may be worth testing. It depends on permissions, screen behaviour and a workable way to detect failure. Direct database access also needs explicit assessment of support, permissions and application rules; being able to write a record does not prove the application will handle it correctly.
If no reliable, permitted route is available, retain a controlled manual handoff while assessing alternatives. Lack of an API does not, by itself, establish that either automation or replacement is the right answer.
This is the discovery work behind system integration: establishing what can move, under whose authority and how completion will be checked.
Decide what happens when a record is wrong
Before building a transfer, agree its operating rules:
- Authority: which system owns each field, and who can approve a correction?
- Identity: how will the same record be recognised on a retry, and how will a later amendment be distinguished?
- Exceptions: where will incomplete or conflicting records go, with what explanation and named owner?
- Reconciliation: how will expected records be compared with those actually accepted by the destination?
Duplicate prevention and reconciliation answer different questions. Avoiding a repeated invoice does not establish that every expected invoice arrived. A successful request also needs interpreting against the destination's documented behaviour, including any later processing or rejection.
Ask to see the failed-record view as well as a successful demonstration. The person running the process needs to know what stopped, what already completed and what action is appropriate.
Change a bounded part, where separation is feasible
Moving one function at a time can make a large change easier to inspect. It also creates a period in which old and new components need to work together.
Microsoft's Strangler Fig pattern describes gradual replacement behind an interface that directs requests to the appropriate component. Its stated limits matter: the original system needs to remain available, with access to make the necessary code changes. It may not fit when requests cannot be intercepted or retirement must happen quickly. The temporary arrangement also brings infrastructure and dependency costs. Microsoft's Strangler Fig guidance.
For a buyer, the test is concrete: name the function being changed, the records it controls and everything that still depends on it. If those boundaries cannot be established, a proposal for gradual change needs more discovery.
Where the missing capability is an internal workflow, a bespoke back-office system is one option to assess alongside adapting or buying software. It needs the same evidence about maintenance, access and operational fit.
Test the changeover before depending on it
Choose a trial that reaches a meaningful operational checkpoint. An order appearing in a test screen is incomplete evidence if the next step cannot invoice it.
Agree acceptance checks with the process owner. Include ordinary records, amendments, missing information, retries and a partially completed batch. Reconcile the results against agreed business rules and approved source records. Differences from the old manual output need investigation; the manual output can contain mistakes too.
Comparison can happen without two processes making live changes. For payments, invoices or payroll preparation, specify which process is allowed to write or release each record. Running both without that control can create duplicate work or transactions.
Define the point at which the change stops if a check fails. State how accepted records will be identified, how incomplete work will be recovered and who decides when to resume. Returning to an old screen is not enough if the new process has already changed live data.
Retirement needs its own checks. The NCSC recommends understanding dependencies, preparing backup and recovery arrangements, testing recovery where possible and confirming replacements work before irreversible actions. NCSC guidance on decommissioning assets.
A hypothetical example: approved timesheets to payroll preparation
Consider a staffing business whose scheduling tool records approved shifts. Its payroll team copies those hours into a separate application. This example illustrates a decision process; it is not an MSD client result or a claim of measured savings.
First, confirm where approval is recorded, which source governs pay rates and how workers match to payroll records. An export containing hours but no usable approval status may be insufficient. The payroll team also needs an agreed treatment for late changes and closed periods.
The four options remain open. Keep and improve might mean configuring an existing supported export. Connect might mean transferring approved records into a payroll import. Modernise in parts might mean replacing an inadequate approval function while retaining scheduling. Replace becomes a candidate if the scheduling system cannot support the required work or continued use presents an unresolved support risk.
Suppose discovery confirms that an approved-record export and a supported payroll import are suitable. A trial could then:
- Collect the agreed approved records, retaining their source identifiers and the information needed to recognise amendments.
- Prepare the import, separating missing worker mappings or unresolved rates for a named person to review.
- Confirm which records the payroll application accepted, then reconcile expected workers, periods and hours before proceeding.
Re-running the same input must not create extra pay lines. A corrected timesheet must follow the agreed amendment process instead of being silently discarded as a duplicate. After a partial import, establish what was accepted before resubmitting anything.
This trial concerns payroll preparation. Correctly transferred hours do not establish that all payroll calculations or reporting are correct. GOV.UK describes additional payroll tasks, including calculating deductions, producing payslips and reporting pay to HMRC. Those responsibilities remain with the payroll process and its accountable people. Running payroll, GOV.UK.
The separate evidence from MSD's own operation
MSD has documented work in a staffing agency run by Michael Szalaty, its technical director. Timesheets are checked against the rota and rate card. Mismatches go to a named person with the reason attached; matched submissions become payroll-ready lines with the source document attached.
That account describes MSD's own staffing operation. MSD is the supplier and the case study at once. It is separate from the hypothetical design above, not an independent client endorsement, and MSD has not published measured savings for the work.
Bring the next discussion down to one process
Before requesting a proposal, gather a sanitised example of the record being handled, the systems and versions involved, and the person who owns the task. Add the current checks, the failure that matters most and any support or contract deadline.
Ask the supplier to explain which options remain feasible, what evidence rules others out and what a trial must demonstrate. The proposal should also name the ongoing support owner and describe what happens when a transfer fails.
If that is the decision you are facing, talk to MSD about the process. A useful first discussion can establish what needs investigating before a particular system or approach is chosen.
Sources and further reading
