Refactoring means restructuring code you keep without changing what it does. Rebuilding means replacing a part of the system with new code. Replatforming means moving a whole system onto new servers and tools, and deciding which parts to move, which to update and which to retire.
If three vendors have handed you three proposals, one for each word, they may not be offering three different jobs. The same words cover different amounts of work from one vendor to the next, so the first step is to make each proposal say exactly what it keeps, replaces and retires.
The Gnar Company does this work as replatforming and as code migrations and refactors, with U.S.-based senior engineers. Below are the definitions, two real decisions (one at an insurer) and the questions to ask each vendor.
What is the difference between replatforming, refactoring and rebuilding?#
The difference is how much of the existing system survives. Refactoring keeps the code and restructures it without changing what it does. Rebuilding replaces a part with new code. Replatforming moves the whole system onto new servers and tools, and decides what to carry over along the way.
- Refactoring. Martin Fowler defines refactoring as "a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior." Users see no change. Gnar refactors a part when it still does its job, and writes tests as it goes.
- Rebuilding. A part of the system is written again with new code. In Gnar's code migrations, the old part keeps running until the new one has passed its tests.
- Replatforming. The system moves to new servers, a new database or new tools. On Gnar's replatforming page, every part of the old system gets a decision: what to move, what to modernize, what to retire, and the order to do it in.
One project can use all three. Gnar's code migration work decides part by part: for each part, Gnar compares what it costs to fix with what it costs to replace.
Why do three proposals use the same words for different work?#
Cloud vendors and software firms use these words differently, so two proposals with the same label can describe very different jobs. Read each proposal for what it changes, and line them up by that.
AWS's migration guidance lists seven strategies, which it calls the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. In those terms, replatforming is "lift, tinker, and shift": the application moves to the cloud with some changes, which AWS says might be few or many. Refactoring, in AWS's list, means changing the architecture to make full use of what the cloud offers.
| Word | In AWS's cloud migration terms | In Gnar's terms |
|---|---|---|
| Replatform | Move to the cloud with some changes to the application | Move the whole system onto new servers and tools, deciding what to move, update or retire |
| Refactor | Change the architecture to make full use of the cloud | Clean up code you keep, without changing what it does |
| Rebuild | Not one of the 7 Rs | Replace a part with new code |
So a "refactor" proposal from a cloud partner may be a larger job than a "rebuild" proposal from a software firm.
How the AARP Foundation chose to replatform#
The AARP Foundation chose to replatform after Gnar's audit showed it would cost less and carry less risk than rebuilding on top of the old code. Its Property Tax-Aide program runs online tools that help low-income older adults apply for property tax relief. The tools launched in 2019 with a different development partner. By 2021, the program's team had real concerns about quality and scalability, and asked Gnar to assess them.
Gnar's audit of the existing code found:
- no integrated testing
- security vulnerabilities
- no CI/CD pipeline, the automated way code gets tested and released
- inconsistent front-end components
- unnecessary complexity for users
- interfaces that did not meet ADA accessibility requirements
That finding made the call. The program also could not go dark, because thousands of older adults relied on the tools every tax season.
So Gnar planned the work in three phases, and kept the existing tools running while their replacements took shape:
- Discovery and stabilization. Gnar took over the code from the previous firm, made the current tools safe to use, and gathered requirements for the rebuild.
- Rebuild while maintaining. Gnar rebuilt the tools with testing and security built in. In total, 14 tools were rebuilt on React and Ruby on Rails.
- New capabilities the old platform could not support. These included address autocomplete, user accounts and a redesigned interface that cut the clicks needed to complete an application by 40% on average.
In the AARP Foundation project, "replatform" meant new infrastructure and rebuilt tools together, which is why the label alone would not tell you the size of the job.
How Vermont Mutual chose what to rebuild on#
Vermont Mutual built the front end of its new quote application on React, chosen after Gnar compared React, Vue and Angular, including which one makes it easiest to recruit and retain engineers. The insurer was rebuilding its property and casualty quote application. It was moving from an off-the-shelf product to a custom one that would give the company more control and give its brokers a better experience. The back end was in place. The team needed front-end skills it did not have in house.
The Vermont Mutual engagement started with a decision before any building. Vermont Mutual was leaning toward Angular, a framework for building web screens. Gnar ran a structured comparison of React, Vue and Angular, recommended React and showed the work behind the recommendation.
Then a senior Gnar engineer joined Vermont Mutual's team as the lead React engineer. James Wong, Director of Product Management at Vermont Mutual, said: "They've been able to integrate with our team. We don't view them as a third-party at all."
Ask each vendor to show how it chose what to build on, and what it compared.
Can you replace a system without switching it off?#
Yes, a legacy system can be replaced while it keeps running: new parts run next to the old system and take over one at a time, so the business keeps working the whole way through. If a new part has a problem, people go back to the old one while it is fixed.
Martin Fowler's name for this is the strangler fig approach, after strangler figs, vines that grow on a host tree and can end up replacing it. He writes that the term is now often used for a gradual approach to legacy modernization, and that it lets both investment and returns arrive gradually and visibly.
Gnar runs its code migrations this way:
- Side by side. Each new part runs next to the system your team is using.
- Tested first. A new part goes live only after it is tested.
- You can switch back. If something is off, your team goes back to the old part while Gnar fixes the new one.
- Then switch off. Once a new part has passed its tests, the old one is switched off.
What should each proposal show before you choose?#
Each proposal should show what it keeps, what it replaces and what it retires, how the old system keeps running during the work, and a price you can compare. Send all three vendors the same questions and compare the answers side by side.
- What code do you keep, replace and retire? Ask for a list by part of the system.
- What did you find in our code? Gnar's replatforming page puts it this way: a quote without discovery is a guess.
- How does the old system keep running? Ask how each new part takes over, and how to switch back.
- How is each part tested before it goes live? Ask what the tests check and who reviews the code.
- What do we own at the end? The code should sit in your own repository, with notes your team can follow.
- Who builds it? Ask for the people, and whether they wrote the plan.
At Gnar, a code migration starts with a free code audit: Gnar reads your code and gives you a ranked list of its risks. A replatforming engagement starts with a fixed-price diagnosis of the system.
When is none of the three the answer?#
Sometimes the right answer to a legacy system is to keep it and change only what people see. If the old system still runs the business reliably and the real problem is the screens people use, a new interface on top of it may be enough.
Gnar's replatforming page answers whether Gnar will replace your system: only if that is the right call, and often it isn't. It describes an experience layer: new screens built on top of the system that keeps your records, which stays in place.
AWS's list also has two outcomes that are none of the three. Retain means keeping an application where it is for now. Repurchase means replacing it with a different version or a product.
And the audit itself can settle it. Gnar's code audit can come back saying your codebase is in reasonable shape, and Gnar will say so.
