Buying principleModernization succeeds when the organization can change a critical workflow more safely. New code is evidence only when users, data and operations can cross the transition with it.
A web application modernization agency should diagnose the blocked change
Start with the change the current system prevents. A distributor may need customers to edit an order before dispatch, but the rule lives across a legacy portal, an ERP integration and a nightly batch. “Replace the portal” is not yet a useful brief.
Ask the agency to trace that workflow from the first user action to the final system record. The investigation should show screens, decisions, data writes, integrations, manual workarounds and recovery paths. That reveals whether the constraint is the interface, the application code, the data model, the supplier contract or the process itself.
GOV.UK advises teams to understand the systems, technical constraints and available alternatives before replacing legacy technology. Its legacy systems guidance also warns against recreating the same process with new technology. A credible partner can recommend a narrower change when a full rebuild adds risk without removing the blocker.
Compare modernization paths before choosing a stack
Modernization is not a synonym for rebuilding. The right move depends on how much of the existing behavior remains valuable, how quickly the constraint must move and whether the team can safely run old and new components together.
Microsoft's 6 Rs guidance separates retain, retire, rehost, replatform, refactor and rebuild. Ask the agency to compare the relevant options against one workflow, not to score the whole application with a single label.
| Path | Useful when | What can remain unresolved |
|---|---|---|
| Retain or wrap | The core behavior is stable and an API or new interface can isolate it | Old operating cost and internal coupling |
| Replatform | The runtime or hosting is the main risk | Product workflow and code structure |
| Refactor | Valuable logic is hard to test, release or integrate | Legacy behavior that the team deliberately keeps |
| Rebuild or replace | The workflow no longer fits the business or a proven product covers it | Migration, adoption and decommissioning risk |
| Retire | Usage and dependency evidence show the capability is no longer needed | Archival and contractual obligations |
Inventory exceptions and dependencies, not just screens
The expensive surprises usually sit behind the visible interface. Require an inventory of scheduled jobs, data stores, exports, permissions, third-party contracts, support routines and exceptions handled by staff.
A subscription dashboard may show one “cancel” button while finance handles credits in a spreadsheet and support reopens accounts through an admin script. Rebuilding only the customer screen creates a cleaner front end and a worse operating system.
Microsoft's modernization assessment guidance expects an inventory, cost view and readiness assessment before planning. Ask for an evidence register that names each dependency, owner, source and test. A product discovery workshop can focus the first workflow when the dependency map is still disputed.
- User roles, permissions and approval boundaries.
- System-of-record fields, retention rules and reconciliation owners.
- Inbound and outbound integrations, including batches and manual exports.
- Peak periods, incident history and recovery procedures.
- Public URLs, analytics events and external links that must survive.
Move one complete workflow through old and new systems
A vertical slice proves more than a new component in isolation. Choose one useful workflow that crosses interface, rules, data and operations, then run it through the modernized path with a controlled fallback.
For the distributor, the first slice might let a small customer group amend eligible orders while the existing portal still handles every other case. The team can compare the final ERP record, support load and failure recovery before expanding access.
The Strangler Fig pattern routes selected behavior to new services while the old system continues to serve the rest. It reduces cutover risk, but the temporary routing layer also adds cost and can become a bottleneck. The agency should state who owns that layer and the condition for removing it.
Data migration needs a reconciliation rule and a route back
A migration is not complete because rows were copied. Every critical field needs a source of truth, transformation rule, validation query, exception owner and rollback decision.
Imagine account status exists in the old database while the new application introduces separate billing and service states. The team must define which state controls access during coexistence, how changes synchronize and what happens when records disagree.
Run at least one rehearsal with production-shaped data, record counts and business-level checks. For orders, that might mean matching totals, currencies, customer ownership and fulfillment status, not only table counts. The proposal should say when old writes stop, how late changes are captured and how long the old system remains readable.
Protect public routes and user habits during the transition
Customer-facing applications carry more than code. Bookmarks, email links, search results, analytics events, accessibility behavior and support instructions all form part of the product contract.
If a help centre and authenticated app share URLs, a new routing scheme can turn useful links into errors even when the new dashboard works. Keep a route inventory, map every changed URL and test redirects, canonicals, sitemap entries and internal links before launch.
Google Search Central recommends testing the new site, mapping old URLs, using permanent server-side redirects and monitoring both sides of a site move. A technical SEO audit can verify the public surface, while product QA must still cover signed-in workflows, keyboard access and saved links.
Demand exit criteria instead of an open modernization programme
A good proposal names the point where the first investment is finished. It should not make “modern platform” an indefinite destination that absorbs every adjacent problem.
For one order workflow, exit criteria could include reconciled records, successful rollback rehearsal, trained support staff, monitored error states and removal of one obsolete batch. Those are observable. “Cloud native” and “AI ready” are not acceptance tests.
The serious objection is that incremental coexistence can cost more than a clean rewrite. It can, especially for a small application with few dependencies. Ask the agency to compare the temporary architecture and dual-running cost with the cutover risk. A web app development agency should be able to build the chosen path, but the modernization proposal must first explain why that path earns its complexity.
Use this checklist before hiring a web application modernization agency
The proposal should make the current system, transition and finish line inspectable. Check these points before comparing team size or preferred frameworks.
- One blocked user or operating workflow is traced end to end.
- Retain, wrap, replatform, refactor, rebuild, replace and retire were considered where relevant.
- Data, identity, integrations, exceptions and public URLs have named owners.
- The first slice crosses the full workflow and has a controlled fallback.
- Migration rehearsals include business reconciliation, not only record counts.
- Coexistence cost, training, support and decommissioning are included.
- Success, stopping and rollback criteria are observable before delivery starts.
Bring Seuil one workflow the current application makes painful
Send Seuil the workflow users struggle with, the dependency that blocks change and one recent incident or workaround. That is enough to map the constraint, compare modernization paths and define a first slice without pretending the whole application needs a rewrite.