Insights
Replatforming moves software to a new platform, refactoring cleans its code, redesign changes what users see. What each changes, and how to combine them. Replatforming moves a product onto a different platform, such as a new runtime, database or hosting model, while keeping most of its code and what it does.
Replatforming moves a product onto a different platform, such as a new runtime, database or hosting model, while keeping most of its code and what it does. Refactoring restructures the code without changing what the software does. Redesign changes what users see and how they get their work done. The first two are meant to be invisible to users. Only redesign is meant to be noticed, and that difference decides how you plan each one.
Vendors and engineers use the three words as if they were one. They change different things and carry different risks for users, and a real programme can combine them. Below are plain definitions, a table of what each path changes and leaves alone, where the cloud-migration "Rs" fit, how a replatform changes users by accident, and a rule for choosing.
The three definitions
Refactoring has the tightest definition of the three. Martin Fowler defines it as a change to the internal structure of software "to make it easier to understand and cheaper to modify" without changing its observable behaviour (Fowler). Code is cleaned, split or renamed, and the product does the same thing afterwards. A refactor that changes behaviour is something else.
Replatforming has no single owner. In AWS's migration guidance it means moving an application to the cloud and introducing "some level of optimization", for example moving a database to a managed service, with "a few or many changes" to the application depending on the goal (AWS). AWS also calls it "lift, tinker, and shift". Outside the cloud the word is used more loosely, for moving a product onto a new framework, runtime, database engine or commercial platform. In all uses, the product's job stays the same and the foundation underneath it changes.
Redesign is our own working term, not a standard one. We mean a deliberate change to the interface, the information architecture or the workflows, so that users do something differently. It can be done with no change to the engineering underneath, and it can be done on top of any of the other two.
What each one changes, and what it leaves alone
| Refactoring | Replatforming | Redesign | |
|---|---|---|---|
| Code | Restructured; same behaviour | Some changed to run on the new platform | Changed where the interface needs it |
| Infrastructure and runtime | Untouched | Changed: the point of the work | Untouched, unless combined |
| Data | Untouched | Moved or converted | Changed only if a new workflow needs new fields |
| Interface | Untouched by definition | Meant to be untouched; check it | Changed: the point of the work |
| Workflows | Untouched | Meant to be untouched; check it | Changed: the point of the work |
| User habits | None needed | None needed in intent; some demanded in practice | Retrained, or protected on purpose |
| Main risk for users | Low, if tests cover behaviour; a defect can slip in unseen | Silent drift: different defaults, renamed fields, lost shortcuts, changed timings | Loss of learned habits and workarounds |
| How users find out | They should not | They should not, but may | They are told and shown |
The "None needed in intent" cells matter. A replatform promises that nothing the user does has to change. Whether that holds is something you check, not something the project plan can assume.
For the redesign column, our guide on redesigning legacy enterprise software without upsetting users covers how to treat habits as requirements and roll changes out in stages.
Where the cloud-migration Rs fit
Much of what ranks for these words comes from cloud migration. AWS lists seven strategies, the "seven Rs": retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect (AWS). AWS's own account says its list builds on five Rs that Gartner outlined (AWS).
Two things in that taxonomy matter for a product team.
Rehost is not replatform. Rehosting, "lift and shift", moves an application to the cloud "without making any changes to the application". Replatforming touches the application a little or a lot. If a quote says "replatform" and means rehost, the user-facing risk is much lower than the word suggests, and the benefit is smaller too.
AWS's "refactor" is not Fowler's "refactoring". In the migration taxonomy, refactor means re-architecting: modifying the application's architecture to take advantage of cloud-native features, which AWS describes as the most complex and costly strategy. In Fowler's usage, refactoring never changes behaviour. Re-architecting can, because moving a monolith's behaviour into new services is a redesign of the internals that users may feel. When someone proposes "refactoring", ask which meaning they intend.
The taxonomy does speak of users in a limited way: AWS notes that a rehosted or relocated application keeps serving users with minimal disruption and downtime, and that a repurchased product needs users trained. What it does not cover is whether the interface or the workflows change for the people using the product, which is the question this page is about.
How a replatform changes users by accident
A replatform is sold as invisible. In practice the new platform has its own defaults, components and conventions, and the team's job is to reproduce the old behaviour on top of them. The risk is the behaviour nobody wrote down, which can change without anyone deciding it:
- field and menu labels that the new component library names differently;
- keyboard shortcuts and tab order that the old widgets happened to provide;
- default sort orders, filters and page sizes;
- saved views, exports and links that other people's work depends on;
- timing: what is instant now and what takes a spinner.
Each of these is small. Together they are the product, from the point of view of someone who uses it forty times a day.
The remedy is to treat the existing behaviour as a specification before the move, and to decide capability by capability what to keep, change or retire. A front-end migration we worked on shows both sides of this. Benchmark Gensuite wanted to move its front end towards a newer framework while preserving the workflows its customers relied on. The case page describes a first pass that modernised components and preserved the existing model, and then notes room to improve the scope selector: the boundary of search could be more explicit, and archive controls could be unified. That is a platform move surfacing a design question, not a technical one. The page records that the work validated the direction and feasibility, and that the modules had not reached customers when it was written (Benchmark Gensuite case).
Choosing and combining them
Combining the paths is normal, and the common case is a replatform with a redesign of the riskiest workflows. A rule for it:
- Decide what users should experience first. List the workflows people depend on and mark each as "must feel identical", "should improve" or "can be retired". This is the design decision, and it comes before any engineering choice.
- Pick the engineering path that delivers it with the least disruption. If the pain is the code, which slows every change, refactor. If the pain is the foundation, such as an unsupported runtime or a database you cannot scale, replatform. If the pain is the interface, redesign, and do not wait for an engineering project to carry it.
- Redesign the riskiest workflows with the replatform, not after it. The common case is a replatform plus a redesign of the few workflows that users struggle with or that the new platform cannot reproduce. If you leave all redesign for "phase two", the product ships the old problems on a new foundation, and the redesign waits on a later phase.
- Move in slices. Fowler recommends the strangler fig approach over a big-bang replacement: build new functionality alongside the old, move behaviour across piece by piece, and find seams to isolate components (Fowler). For users this means they see one workflow change at a time, and the old one can stay available while the new one proves itself.
- Refactor first where it makes the move safer. Code that nobody can change with confidence is hard to replatform. A behaviour-preserving clean-up, backed by tests of what users see, makes drift easier to catch.
This page compares paths inside a modernisation. Whether to modernise or rebuild is a separate decision, covered in rebuild or modernise legacy software.
A worked scenario
Take a generic B2B product: a reporting and approvals tool, built ten years ago on a framework that is no longer supported, with a database that is hard to scale. Its users are finance teams who approve items all day. Three complaints dominate: the approval screen needs too many clicks, exports are slow, and the code is so tangled that a small change takes weeks.
- Step one, the user list. Approving an item must feel identical in sequence and keyboard use. Exports must keep their columns and file names, because other teams' spreadsheets read them. The approval screen's click count is allowed to improve.
- Step two, the paths. The framework and database are the foundation problem, so the programme is a replatform. The tangled code is a refactor, done first in the modules to be moved. The approval screen is a redesign, scoped to that one workflow.
- Step three, the order. Refactor the approval module with tests of what users see. Replatform it behind the old screen, so the interface is unchanged on the new foundation. Then ship the redesigned approval screen as its own, announced change, with the old one available during the transition. Move the next module the same way.
At no point do users meet a change they did not expect, and the redesign they needed is not postponed to a phase that may not arrive. If you are weighing a move like this and want a second view on which workflows must stay the same, we describe how we approach it on our replatforming product design page.