- records compared
- 48,210 orders
- matched
- 48,196
- differences
- 14 · explained 11
- open items
- 3 · owner: finance
- rollback plan
- tested · 40 min
§ 06Modernization
Legacy software modernization services
Replacing a system the business depends on is a risk decision before it is a technical one. We assess what the old system really does, choose how much to change, move the data with reconciliation and switch over only when the numbers match.
- Old system live: donesource of truth
- Parallel run: doneboth systems process
- Reconcile: awaiting a decisionsign-off required
- Cutover: not startedweekend window
- Retire: not startedread-only archive
What this page covers
- 01Assessment
- 02Modernize or replace
- 03Phased replacement
- 04Data migration
- 05Parallel run
- 06Cutover
- 07Rollback
§ 01Symptoms
When a system becomes legacy
“Legacy” is not about age. A system becomes legacy when it limits what the business can do. These are the symptoms that usually lead companies to look for legacy system modernization services.
- change
Small changes take weeks
A new field or a changed rule needs a specialist, a long test cycle and a release window. The business has learned not to ask.
- knowledge
Knowledge sits with one or two people
Nobody else can explain why a calculation works the way it does. Their holidays are a business risk.
- integration
It cannot talk to newer tools
No API, or one so fragile that data moves by export and import. Staff re-key between the old system and everything around it.
- workarounds
Spreadsheets grow around it
Reports, approvals and corrections happen outside the system because it cannot handle them, so the system no longer holds the truth.
- support
The platform is out of support
The runtime, database or operating system no longer receives security patches, and upgrading it means touching everything.
§ 02Assessment
Assessment: what the old system really does
Our legacy software modernization services start here, because every decision depends on knowing what the system does today, including the parts nobody wrote down. The assessment produces five artefacts, and they are useful even if you decide to change nothing.
- functions
Function inventory
Every screen, report, batch job and calculation, marked by how often it is used and by whom. Many legacy systems have features nobody uses and critical behaviour nobody documented.
- used daily
- used at month end
- unused
- data
Data map and quality profile
Tables, files and their meaning; duplicates, orphans and fields used for something other than their name.
- entities
- volumes
- quality issues
- interfaces
Interfaces
Every system that reads from or writes to the old one, including the nightly file someone set up years ago.
- inbound
- outbound
- manual exports
- rules
Embedded business rules
Pricing, rounding, tax and approval logic recovered from code and tested against real outputs, so the new system can reproduce them deliberately.
- calculations
- validations
- risk
Risk register
What could stop the business during transition, how likely it is, and the fallback for each risk.
- impact
- likelihood
- fallback
§ 03Options
Modernize or replace: the options
Application modernization services, including enterprise application modernization services for large multi-team systems, cover a range of options, from leaving the system alone to retiring it. The right answer is often a mix: different options for different parts of the same system.
| Option | What changes | Fits when | Disruption |
|---|---|---|---|
| Retain | Nothing, for now. Wrap it with an API if needed. | It works, rarely changes and is not a security risk. | Minimal |
| Rehost | Move to new infrastructure as it is. | The problem is the servers, not the software. | Low |
| Replatform | Upgrade the runtime or database with small code changes. | The platform is out of support; the logic is sound. | Moderate |
| Refactor | Restructure the code without changing behaviour. | Changes are slow because the code is hard to work in. | Moderate |
| Re-architect | Split into parts, add APIs, change how data flows. | It must integrate or scale in ways its design prevents. | Significant |
| Rebuild | Write a new system that reproduces and improves the old one. | The process has changed and the old design cannot follow. | Significant |
| Replace | Move to a packaged product and retire the old system. | The process is now standard and a product fits it. | Significant |
§ 04Spreadsheets
When the legacy system is a spreadsheet
Business software modernization is not only about old code. In many companies the most critical legacy system is a workbook with macros that only one person understands. It gets the same assessment, migration and reconciliation as any other system.
| BeforeToday: workbook and macros | AfterAs a business system |
|---|---|
| master workbookA workbook with forty tabs is the order book, the price list and the production plan. | recordOrders, prices and plans are separate records with relationships between them, not cross-tab formulas. |
| macrosA macro written by a former employee produces the weekly invoices. | ruleThe invoicing rules are recovered, written down, tested against past invoices and rebuilt. |
| file copies“Final_v3_JM.xlsx” and “Final_v3_JM (2).xlsx” both exist. | doneOne version of each record, with history. |
| email approvalsApprovals happen in email and are pasted into a column. | decisionApprovals are part of the record’s lifecycle, with owner and time. |
§ 05Phased
Phased replacement instead of a big bang
For systems that must keep running, the safest form of legacy application modernization is replacement in parts. An API layer is placed in front of the old system; new functions are built behind it one at a time and traffic moves over function by function (the “strangler” approach). The old system shrinks until it can be switched off.
- API facade: doneold system behind it
- Orders module: donenew · live
- Pricing module: in progressnew · parallel run
- Invoicing: not startedstill on old system
- Reporting: not startedstill on old system
- Old system off: not startedarchive kept
§ 06Migration
Legacy system migration, reconciled
Data migration is where modernization projects succeed or fail. Our legacy system migration services treat it as its own workstream, with repeated trial loads and reconciliations that finance and operations sign off.
- 01phase
Profile
Measure volumes, duplicates, missing values and inconsistent codes in the source data.
- Handed over
- Data quality profile
- 02phase
Map and cleanse
Map every source field to the new model; agree cleansing rules with the data owners; fix what must be fixed before migration.
- Handed over
- Field mapping and cleansing rules
- 03phase
Trial loads
Repeated full loads into a test environment, each followed by automated reconciliation by count and by value.
- Handed over
- Reconciliation report per trial
- 04phase
Cutover rehearsal
The cutover is rehearsed end to end with timings, including the rollback.
- Handed over
- Cutover runbook with timings
- 05phase
Cutover and hypercare
Final load, sign-off, switch, then close support while the first business cycle (a week or a month end) completes.
- Handed over
- Signed cutover checklist
§ 07Scope
What you receive
Ideal when
- A business-critical system has become slow and risky to change
- Spreadsheets and macros have turned into an unofficial system
- The platform is out of support, or knowledge sits with one or two people
You receive
- Assessment: function inventory, data map, interfaces and risk register
- A recommended option with phases and a cutover strategy
- Migrated data with signed reconciliations
- The new system, source code, runbooks and an archive of the old data
Not in scope
- Maintenance of browser applications that are not business systems (a separate Comtau service)
- Mainframe hardware or vendor-specific platform migrations we cannot support
- A “big bang” switch without a rehearsal and a rollback plan
§ 08Questions
Questions about modernization
What are the 7 R’s of modernization?
Retain, rehost, replatform, refactor, re-architect, rebuild and replace. They range from changing nothing (or only the infrastructure) to retiring the system for a new one. Most real projects combine several: for example, rehosting the database now, re-architecting the integration layer, and rebuilding one module that no longer fits the process.
Should we modernize or replace our legacy system?
Replace it when the process it supports has changed so much that the old design gets in the way, or when a standard product now fits. Modernize it when the business logic is sound and the problems are the platform, the code structure or the missing integrations. The assessment exists to answer this question with evidence instead of opinion.
How do you avoid downtime during the switch?
By replacing in parts where possible, running old and new systems in parallel until reconciliations match, rehearsing the cutover with timings, and keeping a tested rollback. The final switch is planned for a low-activity window and is usually measured in hours, not days.
Will the new system just become the next legacy system?
Not if the knowledge survives the project. We recover and document the business rules before rebuilding them, keep rules separate from screens, cover the critical calculations with automated tests based on real historical outputs, and hand over architecture notes and runbooks. Systems turn into legacy when knowledge is lost; the handover is designed to prevent that.
Can our team keep working normally during the transition?
Mostly, yes. The heaviest demands on your team come during the assessment (interviews) and reconciliation (checking differences). We plan those periods with you and avoid month end, peak season and audits.
What does legacy system migration cost?
It depends on the option chosen, the number of functions and interfaces, and above all the volume and quality of the data. The assessment ends with a phased estimate, and each phase can be approved separately.
Next step
Start with an assessment, not a rewrite.
Tell us what the system does, who depends on it and what worries you most about changing it. The assessment answers whether to modernize, replace or leave it alone.
brief.txt · what helps us most
- 01What the system is built on and how old the platform is
- 02Who uses it, and for which processes
- 03Systems and files it exchanges data with
- 04What must not break: month end, peak season, audits