Legacy modernization and cloud migration
Tankar modernises applications that work but have become expensive or risky to change. The work starts with an assessment of the code, the data and the hosting, and produces a plan that moves the system in stages. Each stage is releasable on its own, so the business keeps running while the platform underneath it changes. Where a rewrite is not justified, the assessment says so.
Modernization is a sequence, not an event
The systems worth modernising are the ones the business depends on, which is exactly why they cannot be switched off for a weekend. Tankar plans the work as stages that each ship on their own, so value arrives early and the risk at any single moment stays small.
The assessment comes first
Reading the code, the data and the change history produces a plan, a risk register and an estimate per stage. It also produces the honest answer where a rewrite is not worth it.
Proving nothing broke
Characterisation tests capture what the old system does before it changes. Where the risk justifies it, old and new run side by side on real data and the outputs are compared, which is a stronger check than a QA pass on a spec nobody wrote.
Typical engagements
What this service usually produces, as deliverables rather than adjectives.
- Assessment of an existing application with a written modernization plan and a risk register
- Rehosting from on-premise servers to AWS, Azure or Google Cloud with infrastructure as code
- Replacing a desktop or server-rendered application with a web front end against the existing data
- Extracting one high-change area of a monolith into its own service with its own deployment
- Database migration and schema clean-up with a rollback plan and a data reconciliation report
- Upgrading a framework or runtime that has left support, with tests added before the upgrade
How it runs
The stages this service goes through, and what you see at each one.
Discovery
Code, data, hosting and change history reviewed. What breaks most, what changes most, and what nobody dares touch. Written estimate within 48 hours of the scoped call.
The written estimate follows within 48 hours of the scoped call.
Design
A staged plan where each stage ships on its own, with the cut-over method, the rollback and the data reconciliation written down before any code is changed.
Build
Characterisation tests first, then the change. Sprints with a weekly demo, and the old system stays authoritative until a stage is accepted.
Test
Old and new run side by side on real data where the risk justifies it, and outputs are compared rather than assumed to match.
Launch
Stage cut-over in a planned window with a rollback that has been rehearsed, and monitoring in place before traffic moves.
Run
A period of close monitoring after each stage, then an SLA-backed maintenance plan for the modernised system.
- Timeline
- The migration itself is estimated per stage, because a staged plan is the only honest way to price this work.
- Team shape
- A pod of a named project manager, a senior engineer who owns the plan, engineers and a QA engineer, with a DevOps engineer for the hosting and cut-over work.
Stack for this service
The technologies this work is usually built on, and why each one is used here.
| Technology | Why we use it here |
|---|---|
| .NET and Java runtimes | Most systems in this position were written on one of them, and upgrading in place is often cheaper than a rewrite. |
| Next.js | A new web front end can go live against the existing data before the back end is touched, which is what makes a staged plan possible. |
| PostgreSQL | A well-supported destination for data leaving an unsupported or licensed database, with tooling for migration and comparison. |
| Docker and Terraform | The old environment is usually undocumented; describing the new one as code is what stops the same thing happening again. |
| Playwright | Characterisation tests written against the old behaviour are how a migration proves it changed nothing it was not meant to change. |
Selected work
Case studies where this service carried the engagement. Only outcomes with a source are shown.
Anonymised clientRetail and e-commerceA multi-vendor marketplace with vendor self-service and compliant invoicing
A marketplace where vendors onboard themselves, list and price their own stock, and are paid out against a commission engine with GST-compliant invoices.Services: E-commerce and marketplace development, Custom software development and 1 moreRead the case study
Anonymised clientLogisticsBooking and workforce scheduling for a home-services business
A booking and scheduling platform that assigns jobs to service partners by skill, area and availability without double-booking anyone.Services: Custom software development, Mobile app development and 1 moreRead the case study
Engagement models that fit
The assessment is usually fixed price because its scope is known; the migration runs on time and materials or a dedicated team because staged work is discovered as it goes.
- Fixed priceA defined scope with a clear end state: an MVP, a website, a well-specified module or an integration.
- Time and materialsEvolving products, research-heavy work such as AI features, and engagements where the backlog is set sprint by sprint.
- Dedicated teamOngoing product development where you want engineers who know the codebase and stay on it, working as an extension of your own team.
Questions buyers ask
What buyers ask most about this service, answered before the first call.
Tell us what you are building.
NDA on request. Written estimate within 48 hours of a scoped call. Reply within one business day.