Legacy application replatforming: when it is enough

A manufacturer of industrial pumps has a product catalogue site that distributors in several countries use every day. The content system under it is three major versions behind. The technical director asks two suppliers what to do. One says the site must be rebuilt from nothing. The other says it only needs "replatforming", at a quarter of the price.

The director cannot tell whether the second supplier has found a sensible middle route or is quoting for half the job. Both are possible. Replatforming is a real and often correct choice, and it has clear limits.

What replatforming is

Replatforming means moving an application onto a current platform while keeping what it does and how it is organised. The foundation changes. The building stays. It is one of the seven standard approaches listed in legacy system modernization approaches, and it sits between moving a system unchanged and rebuilding it.

The term comes from cloud migration. Amazon Web Services describes it as the strategy "also known as lift, tinker, and shift": the application is moved, with "some level of optimization" on the way. Among the reasons it gives is one that applies to any ageing system, to "improve your security and compliance stance by upgrading your operating system to the latest version".

The same guidance is frank about how elastic the word is: "you might make a few or many changes to the application, depending on your business goals and your target platform". That sentence explains the technical director's two quotes. A replatforming can be a version upgrade, or it can be most of a rebuild under a smaller name.

For a website, the platform is the content system or framework, its version, the language it runs on and the hosting beneath. Replatforming changes those. The pages, their addresses, the content and the way the site is structured are carried across.

When it is enough

Replatforming answers one kind of problem well: the application is sound and what it stands on is not. Four conditions should hold together.

• The complaint is about the platform. Security fixes have stopped, an upgrade is blocked, the hosting can no longer run the old version.
• The structure still fits. The way content is organised and the way the parts connect suit the business as it is today.
• There is a route. The platform's maker supports moving from your version to the current one, directly or in steps.
• Changes are not the pain. Ordinary requests are delivered in reasonable time. The trouble is exposure, not slowness.

When all four hold, replatforming removes the largest and most urgent item on most lists of technical debt, at far less risk than starting again. It is the "bring up to date" kind of repair described in reducing technical debt, done for the whole foundation at once.

When it is not

Replatforming moves the application as it is. Whatever is wrong with the application arrives on the new platform with it.

• If every change is slow because of how the system is put together, it will be slow on the new version too.
• If the design or the page builder the site depends on has no version for the new platform, that part must be rebuilt, and the job is larger than its name.
• If the business has outgrown what the application does, a newer foundation under the same features changes nothing the users can see.
• If nobody understands the system, moving it does not create that understanding. The behaviour has to be written down first.

In these cases the honest name for the work is a rebuild, in stages. The choice between that and a single rewrite is covered in when rewriting a legacy application is the wrong call.

What to check before agreeing

Five questions show which kind of replatforming is on the table. A supplier who has looked at the system can answer all of them.

• What exactly changes version? Platform, language, database, hosting. From which version to which.
• What does not survive the move? Every add-on and custom part that has no equivalent on the new version, and what replaces each.
• Do the addresses stay the same? For a public site, every page should answer at its existing address afterwards, or be redirected. This is checked from a list, not assumed.
• How is it rehearsed? The move should be run on a copy first, with the content and records compared before and after.
• What is the way back? Until what moment the old version can be restored, as described for larger moves in replacing a legacy system without losing what it does.

Five questions for the pump manufacturer's cheaper quote

The pump manufacturer here is invented. Its catalogue holds two thousand product pages in four languages, a search by specification, and a distributor area for price lists.

The five questions are put to the cheaper quote. The platform would go from three versions behind to current, in two supported steps. Twenty-two add-ons are installed: fourteen have current versions, five are unused and can be removed, and three have no successor. Two of those three are small. The third is the specification search, which was written for the old version and is the reason distributors use the site.

So the answer lies between the two quotes. The catalogue pages, the languages and the distributor area are replatformed, at their existing addresses, after a rehearsal on a copy in which page counts in each language are compared. The specification search is rebuilt as a separate, smaller piece of work with its rules written down first. The first supplier's rebuild of everything was more than the problem needed. The second supplier's price had left out the one part that could not simply be moved.

Before you accept a replatforming quote

• Ask which versions you are on, which are current, and when support for yours ends.
• Ask for the list of add-ons and custom parts, marked: moves as it is, removed, or has no successor.
• Put the five questions to any quote that uses the word.
• Treat anything marked "no successor" as its own piece of work, with its own estimate.

Answering those questions for a public site means knowing every indexed address and what each one earns before anything moves. That inventory, and an outline plan for addresses and redirects, are part of our website modernization assessment. The sample assessment shows both for a real site.

Sources

• Amazon Web Services, About the migration strategies, AWS Prescriptive Guidance.