10decodersSix sentences that come up in almost every modernization conversation.
None of them are about technology. All of them are about risk.
“One person understands the pricing module. He retires next year.”
Manufacturer · CIO“We got a quote for a rewrite. Eighteen months before we see anything.”
Distribution · VP technology“Every change takes six weeks because nobody trusts the regression testing.”
Insurance services · head of IT“The vendor's runtime is going end-of-life and we cannot stay on it.”
Logistics · director of applications“We tried a converter. What came out was unreadable and we still owned it.”
Healthcare services · CTO“Our auditors keep flagging it and we have run out of compensating controls.”
Financial services · CISOThe language is not what makes this risky. Six other things are.
Rewriting PowerBuilder in .NET is an engineering exercise with known answers. Everything below is what actually causes modernization projects to overrun, stall, or quietly break the business. We look for all six before quoting anything.
The rules live in the code, not in a document
Two decades of policy exceptions, customer-specific pricing and regulatory edge cases were implemented directly and never written down. The application is the specification. Any approach that starts from a requirements workshop will rebuild a version of the system that nobody recognises.
Institutional memory is on a retirement schedule
Usually one or two people can explain why a module behaves the way it does. This is the single most time-sensitive factor in the whole project, and it is the one most often left out of the business case.
There is no test suite to tell you if you broke something
Confidence in the current system comes from the fact that it has run for years, not from coverage. Remove that and you are shipping changes blind. Building the safety net is work that has to happen before the rewrite, not alongside it.
The data model carries twenty years of exceptions
Overloaded columns, status flags whose meaning changed in 2011, records that only make sense in the context of a process that no longer exists. Clean-slate schemas collide with this on day one of migration testing.
Integrations you will only discover by turning things off
Scheduled jobs, a reporting database somebody points Excel at, a partner file drop, an interface written by a contractor in 2008. The dependency map is almost never complete at the start of a project.
The business cannot stop while you rebuild
Regulation changes, customers ask for things, competitors ship. A modernization plan that requires an eighteen-month feature freeze is not a plan the business will actually honour, and the parallel-change problem is what sinks it.
Four failure patterns, all of them survivable if you plan around them.
The big-bang cutover
Build the whole thing, test it in UAT, switch over one weekend. Every unknown in the system surfaces at the same moment, in production, with no path back. The larger the application, the more certain this outcome becomes.
The automated converter
A tool translates the source and produces code that compiles and nobody can maintain. You have swapped a legacy system you understand for a modern-looking system you do not. The technical debt moved; it did not reduce.
The two-team divergence
One team maintains the old system, another builds the new one. Every fix shipped to production has to be reimplemented in the rebuild, and the gap widens faster than the new team can close it.
The offshore team without context
Engineers who can write the language but cannot tell whether an odd calculation is a bug or a deliberate business rule. They reasonably assume bug, fix it, and a customer's invoice changes for the first time in fifteen years.
Behaviour first. Code second. Cutover last.
This is a genuine sequence — each stage depends on the one before it, and we do not skip ahead when a timeline gets uncomfortable. The order is the whole risk strategy.
Archaeology
Recover the rules from the source
We read the code, the stored procedures, the batch jobs and the schema, and produce a written rule inventory. Interviews with your long-tenured staff confirm and explain what we found rather than being the only source. What comes out of this stage is an asset you keep regardless of what you decide next.
- Module and dependency map, including the integrations nobody listed
- Business rule inventory with the source location of each rule
- Dead code and dead data identified — often a large share of the estate
Parity harness
Build the safety net before the code
We capture the legacy system's actual behaviour as an executable expectation: real inputs replayed against both systems, outputs compared field by field. This is the artefact that lets everyone stop arguing about whether the rebuild is correct, because the answer becomes a number on a dashboard.
- Production inputs replayed against legacy and rebuilt modules in parallel
- Every difference triaged as bug, deliberate change, or twenty-year-old rounding rule
- The harness stays in place afterwards as your first real regression suite
Strangle
One slice at a time, both systems live
A routing layer sits in front of the application and sends a defined slice of traffic to the new implementation while everything else continues to run on the legacy system. The slice widens only when parity holds. If something is wrong, the route flips back in minutes, not in a weekend war room.
- Users see change gradually, in pieces small enough to absorb
- Rollback is a routing decision, not a restore from backup
- The business keeps operating on a system that has not stopped working
Data
Reconciled, not just copied
Schema modernisation runs behind a compatibility layer with continuous reconciliation between old and new stores, so a data problem is caught by a nightly count difference rather than by a customer. Historical exceptions get explicit handling and documentation instead of a cleanup script.
- Dual-write or change-data-capture during transition, depending on your constraints
- Reconciliation reports as a standing control, not a one-off migration check
- Archive and retention decisions made deliberately, with your compliance team
Retire
Turn it off only when it has earned it
A legacy module is decommissioned when it has carried zero traffic for an agreed period and parity has held under real load, including month-end and year-end. Licences, servers and support contracts are retired on a schedule you approve, and the archaeology documentation is handed over with the code.
- Decommissioning checklist covering licences, jobs, interfaces and reporting
- Month-end and year-end cycles observed before anything is switched off
- Full handover: rule inventory, tests, runbooks, architecture decision records
Traffic routing during S-03 — three points in the same project
Compare them on the questions your board will actually ask.
Automated conversion is fast and cheap and leaves you with code you cannot maintain. A big-bang rewrite gives you a clean system and concentrates all the risk into one weekend. We are arguing for the third column, and this is the honest version of why.
| Dimension | Automated conversion | Big-bang rewrite | Parity-tested strangle |
|---|---|---|---|
| What exists at day 90 | Converted code, untested | A partial system in a dev environment | A rule inventory, a test harness, one module live |
| Undocumented business logic | Carried over, still undocumented | Rediscovered during UAT, or after | Extracted and written down in the first stage |
| When users feel change | All at once | All at once | Gradually, one module at a time |
| If you have to stop | You own unmaintainable code | You own a half-built system | You keep what is already live and documented |
| Rolling back | Restore and re-plan | Weekend recovery operation | A routing change |
| Shipping features meanwhile | Frozen during conversion | Frozen, or built twice | Continues, in whichever system owns the module |
| What you hold at the end | Modern syntax, same debt | A new system and a knowledge gap | Code, tests, documented rules and the team that knows them |
We still keep engineers who can read the systems most firms have stopped hiring for.
That is not nostalgia. You cannot extract rules from a codebase you cannot read, and a team that only knows the target stack will guess at the source.
PowerBuilder
Classic and .NET targets, PFC and custom frameworks, DataWindow logic, embedded SQL. Our deepest legacy practice. See the PowerBuilder page →
Oracle Forms & Reports
Forms 6i onward, PL/SQL-heavy business logic, report estates.
Legacy Java
Struts, EJB 2.x, applets and Swing clients, WebLogic and WebSphere estates, XML configuration sprawl.
.NET Framework & VB6
WebForms, WinForms, classic ASP remnants, VB6 components still in the call chain.
Database-first applications
Where the logic lives in stored procedures and triggers: Sybase, Oracle, SQL Server, Informix.
Departmental systems
Access and VBA applications that quietly became business-critical, and the spreadsheets attached to them.
Batch & integration estates
Scheduled jobs, flat-file interfaces, FTP drops and the reporting extracts everyone forgot were running.
Reporting layers
Crystal Reports, legacy BI and the shadow Excel estate that depends on the old schema staying exactly as it is.
Microsoft is our deepest target stack, and several of these programmes land on Azure and the Power Platform.
“What happens to our roadmap while this is running?”
The honest answer is that a modernization programme costs you some delivery capacity. The dishonest answer is that it costs you nothing. What we can do is make sure the cost is a slowdown rather than a stop, and that nothing gets built twice.
Because modules move one at a time, each change has exactly one owner: it goes into the legacy system if that module has not moved yet, and into the new one if it has. No parallel implementation, no reconciliation backlog.
A paid assessment you own, before anyone signs a modernization contract.
We would rather sell you a small piece of work that tells you the truth than a large one that commits you before either of us knows the shape of the estate.
Weeks 1–4
Assessment
Codebase analysis, dependency and integration map, rule inventory for the highest-risk modules, and a sequenced plan with ranges rather than a single confident number.
Weeks 5–12
First slice
Parity harness built, one module rebuilt and running in shadow, then taking real traffic. This is the gate: if parity does not hold, we say so before you commit further.
Ongoing
Sequenced migration
Modules move on an agreed order that follows business risk, not code convenience. Each one goes through the same shadow, parity, route, hold cycle.
Close-out
Handover and retirement
Legacy decommissioned on your schedule. You receive the rule inventory, the test suite, runbooks and architecture decisions, whether or not we continue with you afterwards.
Five times we would tell you to keep the old system.
Modernization is expensive and disruptive. Sometimes the right answer is not yet, or not at all.
It works and nothing is forcing your hand
No end-of-life runtime, no audit finding, no hiring problem, no roadmap the application is blocking. A stable system that costs little to run is not automatically a liability. We will help you write down what would change that.
The application is genuinely being replaced by a package
If a commercial product covers most of what the system does, buying it is usually cheaper than rebuilding. We would rather tell you that than take a rewrite you will regret at go-live.
Nobody on your side owns the decision
These programmes need one executive who can arbitrate when a rule is disputed and a business unit disagrees with IT. Without that, the project stalls in month four regardless of who is engineering it.
The people who know the system have already left
It is still possible, but honestly harder and more expensive, and the assessment phase gets longer. We will scope it that way rather than discovering it later.
The real problem is the process, not the software
Sometimes the application is being blamed for a workflow the business changed around it. Rebuilding it faithfully will preserve the problem in a newer language.
You want a fixed price on an unassessed estate
Anyone who quotes a firm number before reading the code is either padding heavily or planning to renegotiate. We do the assessment first, and we tell you the range honestly.
Enough engineers to staff a multi-year programme, and enough discipline to keep it small.
Engineers across four offices
Clients delivered for
Offices: Charlotte, Chennai, Madurai, Singapore
27001 and 9001 certified
Trusted by leading enterprises and healthcare teams
