deependra.in

Local time in MUMBAI · UTC+5:30 ·

Legacy modernization

Move an aging system to a modern stack without stopping the business.

Send a brief Replies within one business day · Fixed-price assessment, then a fixed quote per stage

In short

Legacy modernization is moving a system your business depends on to a modern stack in reversible stages, while the old one keeps serving customers. It is for businesses running PHP code, a single-page app or hosting that nobody wants to touch.

I did this for a motoring magazine's CMS: CodeIgniter on shared hosting to Laravel on Google Cloud.

Key facts

Engagement
fixed-scope project
Price
Fixed-price assessment, then a fixed quote per stage
Timeline
An assessment first, then migration in stages on a schedule agreed with you
First step
AssessRead the code, map the data and the integrations, and find out how people really use the system.
Works with
  • Laravel
  • CodeIgniter
  • Next.js
  • React
  • Google Cloud
  • AWS
  • MySQL
  • PostgreSQL
  • Redis
Based in
Mumbai, India · UTC+5:30I plan my working day around my clients' hours. The overlap with your timezone is shown on the contact page.

What it is

What legacy modernization is

Legacy modernization is moving a system the business depends on to a modern stack in stages, while the old system keeps serving customers until the new one has proved itself. I do it for CodeIgniter or hand-written PHP moving to Laravel, single-page React or Angular apps moving to server-rendered Next.js, and shared hosting or a single hand-built server moving to Google Cloud or AWS.

The method has a name, the strangler fig pattern: new parts grow around the old system and take over one route or module at a time, until the old one can be switched off.

For a CodeIgniter app, the step-by-step method is in CodeIgniter to Laravel: a staged migration playbook; this page covers the engagement around it.

Who it is for

Who it is for, and who it is not

Who this is for

  • Businesses running a PHP application nobody wants to touch
  • Teams whose React or Angular single-page app is slow on phones or invisible to search
  • Companies still on shared hosting or a single hand-built server
  • Companies in Japan with aging core systems and too few engineers to replace them

Who this is not for

  • A rewrite for its own sake: if the old system works and rarely changes, I'll say so
  • Migrations where nobody on your side knows how the business actually uses the system

What you get

What you get

  1. A written assessment: what to keep, what to rewrite and what to retire
  2. A migration plan in stages, each one reversible
  3. The new system, running alongside the old one until cut-over
  4. Data migration scripts with verification checks
  5. Permanent redirects for every changed URL, so search rankings survive

Scope of the assessment

The fixed-price assessment comes first. I read the code, map the data and every integration, and find out how people really use the system, which is often not how the documentation says. The written result says what to keep, what to rewrite and what to retire, and splits the move into stages small enough to ship and reverse, starting where the value is highest. Each stage then gets its own fixed quote.

What is migrated and checked

For each stage: the code and its tests, the data with migration scripts that can be re-run, and verification checks that compare row counts, totals and sampled records between old and new before anyone relies on the new copy. Every URL either keeps its address or gets a permanent redirect to its new one, and the full list is tested before and after cut-over. Google's own guidance on site moves is that permanent redirects don't cost PageRank, which is why the redirect map gets as much care as the code.

This is the work behind the TopGear India CMS, moved from CodeIgniter on shared hosting to Laravel on Google Cloud while the newsroom kept publishing; its main pages went from 1–3 min → 3 s.

What it is not

It is not a rewrite for its own sake. If the old system works and rarely changes, I'll say so in the assessment and you'll have spent a small amount to learn that. It also can't succeed without someone on your side who knows how the business actually uses the system; part of the assessment is finding that person. If what you have is mostly a website that needs a new design, website redesign and project refactor is the closer fit.

How it works

How the engagement runs

  1. Step 01

    Assess

    Read the code, map the data and the integrations, and find out how people really use the system.

  2. Step 02

    Plan the stages

    Split the move into steps small enough to ship and reverse, starting where the value is highest.

  3. Step 03

    Run both

    New parts take over one route or module at a time while the old system keeps serving the rest.

  4. Step 04

    Cut over and retire

    Final data sync, redirects checked against the full URL list, monitoring, and then the old system is switched off.

Technologies I use for this

  • Laravel
  • CodeIgniter
  • Next.js
  • React
  • Google Cloud
  • AWS
  • MySQL
  • PostgreSQL
  • Redis

How this works in your market

How this works in Japan

For companies in Japan with aging core systems and too few engineers to replace them, the plan comes first and in writing: phases, deliverables, risks and costs, prepared so it can be translated for stakeholders. I report progress on a fixed rhythm in writing, so nothing depends on a call, and plan around Golden Week, Obon and the New Year holidays. Japan is three and a half hours ahead of me, so my morning is your afternoon.

How this works in the United Kingdom

For UK teams, a migration usually means moving personal data, so the stage plan says where data sits at each step and which processor terms cover it. The simplest route is often that I work inside your UK infrastructure, so the data stays stored in the UK; whether my access from India is a restricted transfer, and which safeguard covers it, is for your counsel to confirm. Your morning is my afternoon, so cut-over windows can sit early in your day with me fully at work.

Proof

Case studies behind this service

FAQs

Questions about Legacy modernization

Will a legacy migration hurt our search rankings?

Not if it's done carefully. Every URL either stays the same or gets a permanent redirect to its new home, and I check the full list before and after cut-over.

Can we keep our backend and replace only the front end?

Often, yes. A new Next.js front end can talk to your existing Laravel, Node or Python backend through its API, which keeps the risk small.

Do you work with Japanese companies?

Yes. I work in English, write detailed plans and documentation, and schedule my working day to overlap Japanese business hours.

Do we have to freeze features during the migration?

Rarely for long. Because the move happens a route or module at a time, the rest of the system can keep changing. Only the area being moved needs a short freeze.

What if a stage goes wrong?

Each stage is designed to be reversible: traffic can go back to the old system while the new part is fixed. That's why the stages are small.

How do you know the data arrived intact?

Verification scripts compare the old and new data, counts, totals and samples, and the results are part of each stage's sign-off.

Should I rewrite or refactor a legacy PHP app?

Four lines decide it: if the old system works and rarely changes, leave it and refactor only what you touch; if patching has stopped paying off because the framework, hosting or data model is the obstacle, rewrite it in stages so the old system keeps serving customers; if nobody knows how the business really uses it, start with the assessment before choosing; and in every case keep each URL or redirect it in one hop. The CodeIgniter to Laravel playbook walks through the stages, and the TopGear India CMS case shows the result.

What is replatforming?

Replatforming, which AWS's migration guidance also calls lift, tinker and shift, means moving an application to a new platform, usually the cloud, with some changes so that it runs well there, such as moving a database to a managed database service. Modernization goes further and changes the code or the framework, as in CodeIgniter to Laravel. In a staged project the two can be separate steps, and the assessment settles the order.

Sources

  1. Japan's IT talent shortage (Nippon.com)
  2. Martin Fowler: Strangler Fig Application
  3. Google Search Central: site moves with URL changes
  4. AWS Prescriptive Guidance: migration strategies

Related writing

Where this work happens

  • Working with teams in Japan · Tokyo

    A software engineer for Japanese companies, working remotely from Mumbai with my morning in your afternoon. It is for teams modernizing legacy systems and adding AI that want detailed plans, documentation and a predictable process.

  • Working with teams in United Kingdom · London

    A freelance senior software engineer for UK teams, working remotely from Mumbai with your morning in my afternoon and the UK GDPR transfer terms written into the contract. It is for scale-ups and agencies that want a senior engineer for platforms, performance and security, with most of the working morning in common.

Teams that start here