Application Modernization Services

What Application Modernization Actually Involves

Application modernization is the work of moving a system that still runs the business onto a foundation that can keep running it. It is rarely a single rewrite. In practice it is a sequence of decisions about which parts of an estate to retire, which to move as they are, which to restructure, and which genuinely need to be rebuilt from the requirements up.

The trigger is usually specific rather than philosophical. A vendor ends support for a runtime. A database version falls out of patching. The engineers who understood the original design have left. Release frequency has slowed until the roadmap is fiction. Or an acquisition means two systems now have to agree on what a customer is. Those are the practical costs of legacy software, and they compound quietly.

unosquare has run this work for 16+ years across payments, treasury, healthcare, insurance, logistics and publishing systems. The pattern we see most often is not a company that refuses to modernize. It is a company that tried once, discovered mid-flight how much undocumented behaviour was buried in the old system, and stopped. Our starting position is that nothing gets rewritten until we can describe what it currently does. That principle drives how we run the engagement after the decision is made.

How a Modernization Assessment Actually Works

An assessment is not a slide deck. It is an evidence-gathering exercise whose output is a sequenced plan someone can actually fund. Four things get established before any code is written.

Inventory and dependency mapping

What exists, what calls what, and what nobody remembers owning. For GTreasury we ran a full audit and census of hundreds of Delphi plugins to map usage patterns and identify deficiencies, which is how the modernization priorities got set. That work produced a transition strategy and modernization roadmap in eight weeks.

Runtime evidence, not org-chart assumptions

Documentation describes intent; telemetry describes behaviour. Call volumes, batch windows, integration traffic and error rates tell you which components are load-bearing and which are dead weight that can simply be switched off.

Test coverage and build reproducibility

Can the system be built from a clean checkout? Is there a test suite that would notice a regression? Where coverage is thin, characterization tests come before any refactoring, because they are the only thing that makes change safe.

Prioritization against the business

Not every workload should be modernized. Microsoft’s Cloud Adoption Framework prescribes weighing business value against technical risk and watching for urgent triggers such as end-of-support deadlines inside twelve months. We use the same logic: high value plus high technical risk goes first, low value plus low risk is left alone.

Rehost, Replatform, Refactor, Rebuild or Replace

This is the decision the whole programme turns on, and it is made per system, not per portfolio. The fuller industry taxonomy is AWS Prescriptive Guidance’s seven migration strategies, the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. In client conversations it usually collapses to five live options.

Option	What changes	When it is the right call
Retire	Nothing. The system is switched off.	Usage evidence shows the application is idle or has had no inbound connection for months. The cheapest modernization is the one you do not do.
Rehost	Hosting only. Lift and shift.	The platform is the problem, not the code. End-of-support hardware or a data centre exit, with a clock running and no appetite for behavioural change.
Replatform	Runtime, database or packaging.	Targeted wins without redesign: a managed database instead of a self-hosted one, containers instead of virtual machines, a supported language runtime.
Refactor / re-architect	Internal structure, same behaviour.	The business logic is correct and valuable but the architecture blocks delivery. Decomposition of a monolith usually lives here.
Rebuild or replace	Everything, or you buy instead.	The design itself is wrong, the source is unmaintainable, or a commercial product now does the job better than a bespoke system ever will.

One caution worth taking seriously: AWS explicitly recommends against refactoring during a large migration, because modernizing an application at the same time as moving it is the most complex and costly of the strategies. Move first, modernize after. We apply the same sequencing, and the trade-offs are worked through in more depth in our guidance on choosing between modernizing and rebuilding.

Two specialisms change the calculus enough to deserve their own treatment: mainframe modernization, where the systems of record and the surrounding batch estate have to be reasoned about together, and database modernization, where the rebuild-versus-refactor question is really a question about who runs the database after go-live.

Phased Cutover, Data Migration and Rollback

Big-bang replacement is where modernization programmes die. Martin Fowler’s strangler fig pattern describes the alternative: begin with small additions built alongside the legacy code base, then move behaviour across piece by piece until the old system is strangled. His argument for it is a risk argument: wholesale rewrites run long, struggle to capture what the system actually does, and deliver nothing until the end, whereas the gradual approach spreads cost and benefit over time.

Phasing the cutover

We slice by capability, not by layer. One workflow, one screen family, or one integration moves to the new path while everything else stays put. A routing layer decides which system serves each request, so traffic can be shifted for a subset of users and pulled back within minutes. For Harvard Business Publishing this is how monolithic, self-hosted systems became AWS microservices and micro-frontends across three business units over a decade-long partnership, and how Athenahealth moved core Perl and Oracle platforms into AWS-based microservices without disrupting care delivery.

Data migration and reconciliation

Data is where the undocumented decades live: columns repurposed years ago, statuses encoded as magic numbers, rows that violate constraints the schema claims to enforce. We profile the source before we design the target, then migrate in rehearsed passes rather than one attempt. After every pass, reconciliation compares row counts, control totals and financial sums between old and new, and discrepancies get explained rather than absorbed. The legacy store stays readable until reconciliation has been clean through a full reporting cycle.

Testing and rollback

Characterization tests capture current behaviour before anything moves, so the question at cutover is whether the new path matches the old one rather than whether it matches a specification nobody wrote. Where the stakes justify it, the two systems run in parallel and outputs are compared on live traffic. Every phase ships with a rollback that has been exercised, not merely documented; an untested rollback is a hope.

Phasing works outside the enterprise core too. RedRock’s thick Windows client became a browser-based, cloud-enabled platform in 20 weeks while remaining integrated with the on-premises systems it still depended on.

Keeping the Lights On While You Rebuild

The constraint nobody plans for is that the old system keeps needing attention. Regulators still expect reports. Customers still raise defects. A modernization plan that assumes feature work stops is a plan that gets abandoned in month three.

We usually run two tracks. One team sustains the legacy system (triage, defects, compliance changes) under an explicit change-freeze policy for the areas being migrated, so the target stops moving while it is being replaced. A second team builds forward. The split is deliberate, because engineers context-switching between excavation and greenfield do both badly.

That model needs people who are comfortable reading unfamiliar code, and enough of them to cover both tracks without starving either. It pairs naturally with staff augmentation when your own engineers should stay on the roadmap while ours do the excavation. Where the target platform is itself new to the organisation, our cloud engineering teams build the landing zone, pipelines and observability before the first workload moves, so the new environment is not being invented during a migration.

Modernization in Financial Services and Insurance

Regulated systems do not change the engineering so much as the sequencing. Audit trails have to be continuous across the cutover. Reporting cannot go dark at period end. Reconciliation is not a nice-to-have but the evidence that the migration was faithful. The practical consequence is that cutover windows are dictated by the reporting calendar, and phases get sized to fit between them.

Our deepest work here is in payments and treasury. For First Data, we migrated from legacy COBOL systems to a modern Java backend and replaced decades-old green-screen workflows with 66 redesigned screens in 24 weeks, on a platform processing a large share of US card transactions. For GTreasury, a treasury and risk management software vendor, we rebuilt 400+ product screens in under 8 months, delivered on time and under the stated $500K budget, with a team onboarded in under two weeks working across Angular, C#, Delphi and SQL Server.

Both industry variants of this work have their own depth: application modernization for financial services and legacy modernization for insurance, where policy administration and claims systems carry their own constraints around rating, forms and state filings.

What Drives Cost and Timeline, and How We Staff It

We do not publish a rate card for modernization, because the number tracks the system rather than the calendar. Five variables move it more than anything else.

• Size and coupling. A million lines with clean seams is cheaper than two hundred thousand where everything imports everything. Coupling determines whether phasing is even possible.
• Existing test coverage. Thin coverage means writing characterization tests before the real work starts. That is unavoidable, and it is often the largest single line item.
• Data volume and quality. Not gigabytes so much as messiness: how many rehearsal passes and how much reconciliation the data will demand.
• Regulatory constraints. Audit, reporting continuity and approval gates narrow when you may cut over, which stretches elapsed time even when effort is unchanged.
• Surviving domain knowledge. If people who understand the original design are still available, discovery is weeks. If they left years ago, discovery is a project of its own.

Staffing follows the same evidence. Teams are typically productive in 2–4 weeks: discovery on day one, 3–5 candidate profiles between days two and ten, onboarding through day twenty-one. Clients usually start with 2–5 engineers on an assessment and scale to 20–50+ once the roadmap is funded, which is how a four-developer pilot at Athenahealth became 35+ engineers across mission-critical areas. Every engineer clears four gates before reaching a client (technical assessment, live coding review, English proficiency, culture fit), and fewer than 2% of applicants are hired. Delivery centers in Mexico, Colombia and Bolivia mean the team works your business day, which is the practical argument for nearshore delivery on work that requires constant conversation with the people who remember how the old system behaves.

For planning your own sequence, our guide to 18 steps to update legacy applications and our overview of strategies for transforming legacy applications cover the groundwork most teams do before they talk to anyone.

Frequently Asked Questions

Start With an Assessment

Tell us what the system does, what it runs on, and what is forcing the decision. We will come back with a sequenced plan and an honest view of what should be retired, moved, restructured or rebuilt.

Not sure whether this should be a dedicated team or a fixed scope? Compare engagement models.

Contact Us