Software Development Blog

Migrating from a Bespoke Ecommerce System

Your ecommerce platform is bespoke. Built from scratch by a developer years ago. Tailored exactly to how your business works.

It does everything you need. But it is also old, fragile, and expensive to maintain. The original developer left. Nobody fully understands how it works. Getting anything changed is slow and costly.

You need to migrate. But bespoke migrations are different to migrating from a standard platform.

Here is what you are dealing with.

Why Bespoke Systems Exist

Someone built you a bespoke system because standard platforms could not do what you needed.

Maybe your products have unusual configurations. Maybe your pricing is complicated. Maybe you sell in a way that does not fit the standard ecommerce model.

Whatever the reason, a bespoke system made sense at the time.

Ten years later, it is a liability. Nobody knows how to work on it. Every change requires a developer. Security updates are manual. Scaling is difficult.

But the business logic built into that system is valuable. It represents years of refinement. Migrating means extracting that logic and rebuilding it properly.

The Documentation Problem

Standard platforms have documentation. Forums. Tutorials. Thousands of developers who know how they work.

Your bespoke system has none of this.

If you are lucky, there is some developer documentation. Usually out of date and incomplete.

More often, there is nothing. The only documentation is the code itself. And understanding the code means understanding decisions made years ago by someone who is no longer around.

This makes discovery hard. You need to reverse-engineer how the system works by reading code and testing behaviour.

Budget significant time for this.

The Data Problem

Standard platforms structure data in standard ways. Products have SKUs, names, prices, variants. Customers have email addresses and order history. Orders have line items and totals.

Bespoke systems structure data however the original developer decided.

Maybe products are not products. Maybe they are "stock items" or "assets" or something else entirely. Maybe variants are handled through a custom table with relationships nobody remembers. Maybe pricing is calculated on the fly from multiple data sources.

You cannot just export and import. You need to understand the data model, then map it to the new platform's structure.

This often means writing custom export scripts. And spending days untangling relationships between tables that made sense ten years ago but are baffling now.

The Feature Problem

Your bespoke system does things in specific ways because that is how your business works.

Standard platforms do things in standard ways because that is what most businesses need.

These do not always align.

Custom checkout flow. Maybe your checkout is unusual. Additional steps. Custom fields. Complex logic. The new platform might not support this out of the box.

Bespoke pricing. Maybe you have complex pricing rules. Customer groups. Volume discounts. Special deals. Contract pricing. The new platform handles pricing differently.

Unusual product structure. Maybe your products are not simple items with variants. Maybe they are configurable systems with dependencies. Maybe they are built-to-order with hundreds of options.

Custom admin. Maybe your team uses the admin in specific ways. Custom reports. Bulk editing tools. Specific workflows.

All of this needs rebuilding or replacing on the new platform.

Sometimes you can use standard platform features. Sometimes you need apps. Sometimes you need custom development.

Work out which early in the process.

The Integration Problem

Your bespoke system probably talks to other systems. But the integrations are also bespoke.

Maybe there is a custom sync with your accounting software. Maybe stock updates come from a warehouse system through a proprietary API. Maybe orders push to a fulfilment system through a custom webhook.

These integrations work because they were built specifically for your bespoke system.

When you migrate, they all break.

You need to rebuild every integration. Sometimes this is straightforward if the other system has a modern API. Sometimes it is complicated if the other system is also bespoke or legacy.

Budget significant time and cost for integration work. It often takes longer than the actual platform migration.

The Risk of Translation

The biggest risk in bespoke migrations is translation errors.

Your bespoke system does something in a specific way. You try to recreate that behaviour on the new platform. But the translation is not quite right.

Maybe the pricing calculation is slightly different. Maybe the stock allocation works differently. Maybe the order workflow misses a step.

These differences are subtle. They do not show up in basic testing. They appear in edge cases. A specific combination of products. A customer with a particular account type. An order with multiple discounts.

The only way to catch this is comprehensive testing that covers not just happy path but all the weird scenarios your business encounters.

Should You Migrate or Rebuild?

Sometimes migrating is not the right answer. Sometimes rebuilding from scratch makes more sense.

Migrate if:

• The bespoke system mostly works
• The business logic is stable
• You just need a more maintainable platform
• Historical data is important

Rebuild if:

• The bespoke system is so custom it cannot be mapped to any standard platform
• The business has changed significantly since it was built
• The features are so outdated you want to start fresh
• The cost of understanding and migrating exceeds rebuilding

There is no shame in rebuilding. Sometimes the cleanest solution is to accept that the old system served its purpose and build a new one properly.

How Long It Takes

Bespoke migrations take longer than standard platform migrations because everything is harder.

Discovery takes longer because you are reverse-engineering instead of reading documentation.

Data mapping takes longer because the structure is custom.

Feature replication takes longer because nothing maps cleanly.

Integration work takes longer because everything is custom.

A migration that would take 8 weeks from a standard platform might take 20 weeks from a bespoke system.

Factor this into your planning and budget.

The Cost Reality

Bespoke migrations are expensive.

You are paying for developers to understand a custom system, extract data properly, rebuild custom features, and test everything thoroughly.

Expect to pay 2x to 3x what a standard platform migration would cost.

This sounds expensive until you consider the alternative: continuing to maintain an unmaintainable system.

What To Do Next

Start with thorough discovery.

Get a developer who is good at reverse-engineering to look at your bespoke system. Understand what it actually does. Document the critical business logic.

Then decide whether migration or rebuild makes more sense.

Only commit once you have a clear plan based on what you actually have.

Need help with a bespoke migration? Our Platform Migration Service includes the technical expertise to unpick custom systems and migrate them properly. Book a discovery call and we will assess what you are dealing with.