How to rescue an inherited ecommerce platform

Most platforms that need rescuing are not failing outright. They take orders, the product pages load and the monthly figures look broadly as they should. The difficulty is that nobody quite understands how. The agency relationship ended. A freelancer who knew every quirk moved on and stopped replying. A replatforming project was paused half-way, leaving two systems partly connected. Or the developers who built it left one by one and took the knowledge with them.

The symptoms are familiar. Small changes take weeks because nobody is sure what they will break. The same faults return after each supposed fix. Promotions are planned around what the site can tolerate rather than what the business wants, and every release before a busy trading period feels like a gamble. None of this means the platform has to be thrown away. In most cases an inherited system can be brought back under control without starting again, provided the work is done in the right order.

Stabilise and protect first

The first priority is not the code. It is making sure the business actually controls what it depends on. It is not unusual to find the domain registered to a former agency, the hosting account billed to a freelancer’s personal card, or the only administrator login for the payment gateway belonging to someone who left long ago. Until that is resolved, the brand is exposed to decisions it cannot influence.

Start with a list of every account the site relies on, and confirm that the business holds ownership rather than borrowed access:

• domain registrar and DNS provider
• hosting, cloud or platform account, including billing
• code repositories, if any exist
• payment gateways, fraud tools and merchant accounts
• apps, extensions and their licences
• email delivery, analytics, tag management and search consoles
• API credentials for ERP, warehouse, marketplace and marketing integrations

Once ownership is clear, secure it. Remove access for former suppliers and staff, rotate passwords and API keys that have been shared widely, and turn on two-factor authentication wherever it is offered. Take care: an integration quietly running on a former developer’s credentials will stop the moment those credentials are revoked, so it helps to know what uses what before switching anything off.

Then make sure recovery is possible. Confirm that backups exist, that they cover both the database and the files, that they are stored independently of the live server and, most importantly, that someone has restored one successfully. A backup nobody has tested is a hope rather than a safeguard. Alongside this, put basic monitoring in place: uptime checks, alerts for failed payments or an unexpected drop in orders, and error logging that someone actually reads. The aim is simply to hear about problems before customers do.

Understand what you have

With the immediate risks contained, the next task is to document the system as it really is, which is rarely how it was specified. Establish the platform and version, how far behind supported releases it has fallen, and what has been customised. On a hosted platform that usually means the theme, apps and any custom scripts; on a self-hosted or bespoke build it extends to core modifications, extensions and server configuration.

Integrations deserve particular attention, because they are where inherited platforms most often come apart. Map where data flows: how orders reach the warehouse or logistics provider, how stock levels come back, how products and prices are maintained, how customer records and consents reach the CRM, and how transactions reach the finance system. Note which of these run in real time and which depend on scheduled jobs, and find out where those jobs actually run. An overnight stock feed running on a forgotten server is more common than anyone would like.

As you go, keep a plain record of what is fragile: the areas people avoid touching, the manual workarounds the operations team has quietly adopted, and the errors everyone has learned to ignore. That last category is often the most revealing.

Triage by commercial risk

A review of an inherited platform almost always produces a long list of issues. The mistake is to work through it in the order it was found, or to start with whatever irritates the developers most. Priorities should follow commercial risk.

Anything that stops customers paying comes first: checkout errors, payment failures, broken address lookups, faults on particular browsers or devices. Next is anything that leads the business to sell what it cannot deliver, or fail to deliver what it has sold, such as stock that does not synchronise, orders that never reach fulfilment, or refunds that fall out of step with the finance system. Security exposures and unsupported software follow, then performance, then the wider backlog. For a premium brand the bar sits a little higher than usual, because a clumsy checkout or a cancelled order on a sold-out piece does damage that outlasts the transaction.

Fix in place, rebuild parts or replatform

Once the picture is clear, the larger question can be answered honestly. There is often pressure to replatform, sometimes from a new supplier keen to start afresh, sometimes from a team worn down by the current system. It can be the right answer, but it is expensive and disruptive, carries its own risks, and does not by itself change the habits that caused the problem.

Fixing in place is usually right when the platform is still supported or can be upgraded without extraordinary effort, the underlying data is sound, and the difficulties stem mainly from missing documentation, neglected maintenance or a handful of poorly built customisations.

Rebuilding parts makes sense when the core platform is serviceable but specific components are not: an integration that fails every week, a checkout customisation that blocks upgrades, or a theme altered so heavily that it can no longer be maintained. Replacing those pieces in isolation often removes most of the pain at a fraction of the cost.

Replatforming becomes the sensible option when the platform has reached end of life with no realistic upgrade path, when security cannot reasonably be assured, when keeping the current system alive clearly costs more than moving, or when the business has genuinely outgrown what the platform can do. Even then, the understanding gained during stabilisation makes the migration far safer.

Red flags that suggest a deeper problem

Some findings indicate that the difficulties go beyond neglect. They do not automatically mean a rebuild, but they should weigh on the decision:

• there is no version control, or the live site no longer matches what is in the repository
• changes are routinely made directly on the live server
• the platform is out of support and cannot be upgraded without rewriting its customisations
• the platform’s core files have been edited rather than extended
• payment details, passwords or credentials are stored in ways they should not be
• the same data is edited in several systems with no clear source of truth
• nobody can explain why certain code, apps or scheduled jobs exist

Stop it happening again

A rescue is only worthwhile if the platform does not drift back into the same condition. The practices that prevent this are not complicated, but they need to be insisted upon.

All code should live in version control that the brand owns, with every change traceable. There should be a staging environment close enough to the live site to test changes properly, and a repeatable way of deploying to production. Documentation should cover the architecture, integrations, scheduled jobs and a register of accounts and credentials, updated as part of each piece of work rather than at the end of a contract. Code should be written on the assumption that someone else will take it over, because eventually someone will.

Support arrangements should also be explicit. Everyone should know who responds when something breaks at the weekend, how quickly, who can approve changes, and what happens to access and documentation if the relationship ends. Handover should be designed into the arrangement from the start, not negotiated at the point of departure.

If you have inherited a platform that still trades but no longer feels fully under your control, a technical review is usually a sensible first step. Tell us what isn’t working and what worries you, and we can help establish where the real risks lie and what it would take to put things right.