Many businesses run on a front end built eight or ten years ago: jQuery plugins stacked on top of each other, PHP templates with JavaScript sprinkled in, or an AngularJS admin panel nobody wants to touch. It works - mostly - but every new feature is slow to build, bugs reappear, and finding developers who want to work on it gets harder each year.
Moving to React is a common answer. The risky part is not React; it is the migration itself. This guide lays out a phased plan that keeps your business running while the front end is modernised.
Signs it is time to migrate
- Small UI changes take days because one change breaks something elsewhere.
- The app is slow or awkward on phones.
- It depends on technology no longer supported - AngularJS reached end of long-term support in January 2022, and many old jQuery plugins are abandoned.
- New developers struggle to understand the code, and the original developers have left.
- You want a mobile app, but nothing in the current front end can be reused.
- Security scans flag outdated front-end libraries.
If several of these apply, a planned migration is usually cheaper in the long run than continuing to patch.
Big-bang rewrite vs phased migration
| Approach | How it works | Risk | When it makes sense |
|---|---|---|---|
| Big-bang rewrite | Build the whole new front end separately, switch over on one day | High - long period with no visible value, surprises at launch | Very small apps, or systems that must change completely anyway |
| Phased (strangler-fig) migration | Replace the old system section by section, both running side by side | Lower - value delivered continuously, problems found early | Most business applications |
The name "strangler fig" comes from a plant that grows around a tree until it replaces it. In software, new React screens gradually take over routes from the old front end until nothing old remains.
The step-by-step plan
Step 1: Discovery and inventory
Before writing any React code, map what exists.
- List every screen, page and user flow, and who uses each one.
- Note which screens matter most for revenue or operations - checkout, order entry, billing, dealer ordering.
- Identify the business rules hidden in front-end code: price calculations, GST logic, validation rules, discount conditions. These are the easiest things to lose in a migration.
- Document how the front end talks to the back end. Does it call APIs, or does the server render HTML directly?
- Pull analytics: which pages get traffic, and which are barely used. Unused screens might not need migrating at all.
The output is a written inventory and a prioritised list.
Step 2: Decide the target architecture
Key decisions to make up front:
- Framework: For public pages that need SEO, Next.js is the common choice. For a purely logged-in admin panel, a client-side React setup with Vite can be enough.
- Language: TypeScript from the start.
- Design system: A shared component library so new screens look and behave consistently.
- Data fetching and state: A consistent approach agreed before the first screen.
- API layer: If the back end does not expose APIs, plan which endpoints are needed. This is often the biggest hidden piece of work and may involve your back-end team or our Node.js developers.
Step 3: Set up the bridge between old and new
Decide how old and new will coexist. Common options:
- Route-level split: A reverse proxy such as Nginx sends certain URLs (say, /orders) to the new React app and everything else to the old system.
- Embedded components: React components are mounted inside specific parts of existing pages - a new search bar or product configurator inside an old template.
- Micro-frontend shell: For large systems, a shell application loads old and new sections side by side.
Shared login is essential: a user must not have to sign in twice when moving between old and new screens. Plan how sessions or tokens will be shared.
Step 4: Build the foundation
Before migrating real screens, build:
- Project setup with TypeScript, linting, formatting and testing.
- The design system's core components: buttons, inputs, tables, modals, layout.
- Authentication integration.
- A CI/CD pipeline that tests and deploys automatically.
- Error tracking and analytics.
This feels slow, but it makes every following screen faster and more consistent.
Step 5: Start with a pilot screen
Pick one screen that is valuable but not the most critical - for example, the order history page rather than checkout. Migrate it, release it to a small group of users or internal staff, and learn. You will discover gaps in APIs, authentication or design early, when they are cheap to fix.
Step 6: Migrate in priority waves
Group remaining screens into waves, balancing value and risk.
| Wave | Typical contents | Goal |
|---|---|---|
| Wave 1 | Pilot plus low-risk, high-traffic screens | Prove the approach, show visible improvement |
| Wave 2 | Core workflows - order entry, customer management | Deliver the biggest productivity gains |
| Wave 3 | Revenue-critical flows - checkout, payments | Migrate with extra testing and staged rollout |
| Wave 4 | Rarely used screens and reports | Complete the move or retire unused screens |
| Final | Remove old code, routes and libraries | Eliminate maintenance of two systems |
For each screen, write automated tests that confirm the new version produces the same results as the old one - especially for calculations such as taxes, totals and discounts.
Step 7: Protect SEO for public pages
If any migrated pages are public:
- Use server rendering or static generation.
- Keep URLs identical wherever possible; 301-redirect any that change.
- Carry over titles, meta descriptions, headings, structured data and internal links.
- Compare page speed before and after.
- Submit the updated sitemap and watch Google Search Console after each release.
Our SEO services team typically reviews these steps during migrations.
Step 8: Train users and gather feedback
Staff who use the system daily notice what developers miss. Release with short guides or videos (in Hindi where helpful for your team), collect feedback through a simple form or WhatsApp group, and fix friction quickly.
Step 9: Decommission the old front end
The migration is not done until the old code is removed. Leaving it in place "just in case" means maintaining and securing two systems. Once every route is served by React and usage confirms nobody hits the old paths, retire them.
Keeping the business on board during the migration
Technical plans fail when the people using the system lose patience. A few habits help:
- Show progress every two weeks with a live demo of migrated screens on staging, not a status report.
- Name an owner on the business side - someone from sales, operations or accounts who tests each wave and signs off.
- Freeze non-urgent feature requests on the old system, or every new feature has to be built twice.
- Publish a simple roadmap showing which screens move in which wave, so teams know what to expect.
- Measure what matters to users: page load on phones, steps to complete common tasks and support complaints before and after each wave.
Common migration mistakes
- Migrating without an inventory, then discovering forgotten screens late.
- Losing hidden business rules that lived in old JavaScript.
- Redesigning everything at the same time as changing technology, which multiplies risk. It is often wiser to modernise the technology first and refine the design in later waves - unless the design is a core problem.
- Ignoring the API gap between an HTML-rendering back end and a React front end.
- No shared authentication, forcing users to log in twice.
- Never finishing, leaving two systems running indefinitely.
Key takeaways
- A phased, strangler-fig migration is safer than a big-bang rewrite for most business apps.
- Start with a full inventory of screens, users and hidden business rules.
- Decide the target architecture, API layer and design system before migrating screens.
- Pilot one screen, then migrate in waves with automated comparison tests.
- Protect SEO with server rendering, preserved URLs and 301 redirects.
- Finish the job by removing the old code.
Running on an ageing front end and wondering where to start? Book a free consultation and we will assess your current system and prepare a written, phased migration plan. Explore our React JS development and custom software development services.
