Web application modernization, migration and maintenance
For the application your business already depends on: an assessment first, then improvements and migration in small, reversible steps, then maintenance that keeps it secure.
| module | today | target | state | traffic |
|---|---|---|---|---|
| Customers | PHP 5 · MySQL 5.5 | Laravel 11 · PostgreSQL | modern | /customers → new |
| Orders | PHP 5 · stored procs | Laravel 11 · PostgreSQL | migrating | /orders → new (reads), old (writes) |
| Invoicing | PHP 5 · cron scripts | queue jobs + accounting API | next | old |
| Reporting | nightly SQL exports | reporting views | legacy | old |
| User admin | custom auth | SSO via identity provider | modern | new |
| FTP price feed | nightly FTP upload | - | retired | replaced by ERP API |
3 of 6 modules moved · business running throughout · next cut-over: invoicing
symptoms
Signs an application needs attention
None of these means the application must be replaced. Each means it needs a plan.
-
slow change
Small changes take weeks
Every change touches code nobody fully understands, so the team tests by hand and releases rarely.
-
outdated
The framework or language is out of support
Security patches have stopped, hosting providers are retiring the runtime, and libraries can’t be upgraded.
-
key person
One person understands it
The original developer has left or is overloaded, and there is little documentation or test coverage.
-
integration
It can’t connect to newer systems
Data moves by CSV exports and FTP because the application has no usable API.
-
reliability
It breaks under load or on updates
Month-end, seasonal peaks or any server update are a risk to the business.
start here
Start with an assessment
Our web application modernization services always start here. Before recommending anything, we read the code, the data and the infrastructure, and talk to the people who use and run the application. You get a written report you can act on with us or without us. For older systems that are not web applications, see legacy software modernization.
- dependenciesPHP 5.6 and 41 packages past end of lifehigh
- securityPasswords hashed with MD5; no rate limiting on sign-inhigh
- dataOrder totals duplicated in 3 tables, 0.4% disagreemedium
- operationsManual FTP deployment, no staging environmentmedium
- knowledgeNo tests; business rules only in code commentsmedium
- architectureCustomers and orders modules separable; invoicing tightly couplednote
you receive
- Findings rated by risk
- Options with effort and trade-offs
- A sequenced plan, smallest safe step first
options
Modernization options, from least to most change
People ask about the “7 Rs” of modernization. In practice, the decision is usually among these six, often a different one per module.
| option | what it means | fits when | risk |
|---|---|---|---|
| Keep and stabilise | Patch security issues, add monitoring, tests and documentation | The application works and will be needed for a while yet | Low |
| Rehost | Move to new infrastructure or cloud with minimal code change | The hosting is the problem, not the code | Low |
| Replatform | Upgrade the runtime, framework or database, and adopt managed services | The code is sound but its foundations are out of support | Medium |
| Refactor | Restructure code to make it testable and changeable, behaviour unchanged | Business rules are right but change is slow and risky | Medium |
| Rebuild | Write a module again on a modern stack, behind a routing layer | The structure prevents change or the platform is a dead end | Higher, controlled per module |
| Replace | Retire the module in favour of a product or another system | The capability is now a commodity | Varies: data and process migration |
migration
Migrating without stopping the business
Good web application migration services run the old and new systems side by side, because that is when migration is safest. A routing layer decides which code answers each part of the application; modules move one at a time, each cut-over reversible, until the old system has nothing left to do.
-
before
Everything runs on the legacy application.
-
during
The router sends /customers and /orders to new code; data synced both ways.
-
after
Legacy switched off after a last reconciliation; one data store.
data migration
Moving the data, and proving it moved
Data migration is where most migrations go wrong. Every step has a check that has to pass before the next one.
-
01 map
Map
Every source table and field mapped to the target model, including the rules hidden in old code.
-
02 clean
Clean
Duplicates, orphans and invalid values found and resolved with the business owners.
If not: ambiguous record → owner decides
-
03 rehearse
Rehearse
Full dry runs on copies of production data, timed and repeated until they are boring.
-
04 reconcile
Reconcile
Counts, totals and samples compared between old and new, per entity.
If not: mismatch → stop and fix
-
05 cut over
Cut over
Final sync in a planned window, with the routing switched module by module.
-
06 rollback
Keep a way back
The old system stays available read-only until the new one has run cleanly through a full business cycle.
maintenance
Web application maintenance services
Maintenance is a service of its own, whether we built the application, modernized it, or are taking it over. The scope is agreed in writing, and requests move through visible states.
| area | what’s included | how often |
|---|---|---|
| Security | Patches for the runtime, framework and libraries; vulnerability scanning | Continuously; critical issues as they appear |
| Dependencies | Planned upgrades so the stack never falls out of support again | Quarterly review |
| Monitoring | Uptime, errors, performance and queue health, with alerts routed to the agreed on-call contact | Always on |
| Backups | Automated backups and restore tests that prove they work | Daily backups, regular restore drills |
| Fixes | Bugs triaged by severity with agreed response times | As reported |
| Improvements | Small changes from a backlog you prioritise | Each cycle |
| Reporting | Health, incidents, work done and recommendations | Monthly |
Taking over an application from another team
- Access to code, infrastructure, domains and third-party accounts transferred to your ownership.
- A first assessment and a stabilisation list before new features.
- Tests added around the paths that would hurt most if they broke.
- Business rules written down as they are discovered.
faq
Frequently asked questions
What does application modernization mean?
Application modernization means improving an existing application so it is secure, maintainable and able to change again: upgrading or replacing outdated frameworks, restructuring code, moving infrastructure, migrating data, adding APIs, or rebuilding parts of it, usually in stages while the business keeps using it.
Should we rewrite the application or refactor it?
It depends on the assessment. If the business rules are sound and the code can be made testable, refactoring and upgrading in place is lower risk. If the platform is a dead end or the structure prevents change, rebuilding module by module behind a routing layer avoids a risky big-bang rewrite.
Can you work on code another team wrote?
Yes. Most modernization work starts with code written by someone else. We begin with an assessment, add tests around the critical paths before changing them, and document the business rules we find so the knowledge no longer lives in one person.
How long does a web application migration take?
It depends on the size of the application, the quality of the data and how many integrations it has. Because migration happens module by module, the first improvements usually reach production long before the whole application is migrated.
Will there be downtime during migration?
The goal is none for users. Old and new run side by side behind a routing layer, data is synchronised and reconciled, and each cut-over is reversible. Where a short maintenance window is unavoidable, it is planned and rehearsed.
What do web application maintenance services include?
Security patches and dependency upgrades, monitoring and alerting, backups with tested restores, bug fixes, small improvements, hosting management and an agreed response time for incidents, plus a regular report on the application’s health.
How much does a cloud migration cost?
It depends on whether the application is moved as-is, adapted to managed cloud services, or partly rebuilt, and on the volume of data and the number of environments. An assessment produces options with effort for each, so the decision is made on evidence.
project brief
Request an application assessment
Tell us what the application does, what it runs on and what worries you about it. We reply with questions and a proposal for the assessment.
- 01
We read it and reply with the questions that decide scope.
- 02
A working session mapping records, roles, rules and integrations.
- 03
A written proposal with phases, assumptions and what each phase delivers.