Platform Migrations Aren't Website Design Projects

Platform migrations fail more often than they should. The cause, rather than being bad work, is almost always because everyone involved missed key considerations they didn't know about. If you're a business or agency moving from a legacy platform to WordPress, Shopify, BigCommerce, or any modern CMS, this article will help you understand where migration projects go wrong and how to avoid a massive headache.

How the Mismatch Happens

A business hires a design agency because...well, that's who builds websites, right? The agency does what they're good at, like design, templates, front-end development. However, a platform migration isn't just a website redesign. There's a whole integration layer underneath. Payment gateways, ERPs, subscription management, accounting feeds, and all that needs to be rebuilt on the new platform. Unless you've hired a Big Agency, all that work sits outside what most shops are set up to deliver. There's no-one on the team who can spot the gaps until the project is already underway, and that's when things get expensive.

Here's how things usually start. The agency scopes what they've been asked to scope. They'll put together a proposal covering design, templates, front-end build, maybe some content migration. It's good work and it's what they do every day. The problem is that any business that's been running for more than a couple of years will have accumulated a stack of connected systems, and those connections are where the real complexity lives.

If you haven't been through one of these projects before, you'll have no idea about how complex things can get.

So you end up with a project where the visible part is moving along nicely but the bit that actually determines success for the business isn't on anybody's plan. Someone dropped the ball. They just didn't realise it because they didn't have the expertise to know better. So the project was framed as a website build from the start when it was far bigger.

What's Actually Underneath

This type of project is my bread and butter, and the pattern is almost always the same regardless of the platform. An e-commerce business moving between platforms will typically have five to ten third-party systems all wired together. Payment gateways (Stripe, PayPal, sometimes both plus the platform's own), subscription management, an ERP for fulfilment, something piping transactions into the accounting software, a marketing automation tool, and usually a couple more that nobody remembered to mention at the start. Large content-heavy sites, like news publishers and membership organisations, have a different but equally complex set of dependencies: editorial workflows, access control, syndication feeds, and integrations with publishing tools or paywall systems.

All of those systems talk to each other through APIs and webhooks, and every one of those connections has to be unpicked, understood, and reassembled on the new platform. This is assuming the new platform even supports them the same way, which isn't always the case. So the finance team can't sign off on going live until the ERP integration works; without it they have no way to record sales. The marketing team can't run their relaunch campaign until they know the date is solid. Customer service needs the new subscription management system working before they can handle enquiries. And all of that has to be coordinated across vendors who live in silos and don't report to each other.

That's plumbing, not page design.

Somebody needs to map all of it before anyone writes a line of code or designs a single page. When I come onto a migration project, the first thing I do is a structured discovery phase. I know from experience that it's vital to document how everything on the old platform translates to the new one. This means how the business actually operates as well as code and third-party services. On one project that meant cataloguing requirements across business processes, integrations, customer workflows, and admin functions. It's not glamorous work, but without it you're building on guesswork.

Where the Gap Opens Up

The agencies on these projects are usually good shops. They have strong portfolios and experienced teams. (Why else would they have been hired in the first place?) But a few weeks in, the client asks for an architecture diagram showing how the integrations connect and the agency's response is some version of "the integrations aren't part of our scope."

And quite honestly, they usually have a point. They were hired to design and build a website. The contract was broad enough that "design and build" could cover anything from a complete platform implementation to what one client described to me as "a set of pretty pictures." The scope gap was there from day one but it took time for anyone to notice.

On another project, the agency lead had to explain to the client that back-end functionality was the platform vendor's responsibility, right at the point when everyone was expecting to see the site actually working. That's a reasonable assumption if you're used to building marketing sites where the platform handles everything out of the box. But none of that mattered half-way into the project. Somebody still needed to deal with the payment token migration, the subscription data, the ERP integration, the accounting feeds, and the go-live sequencing. No-one on the team had the expertise and I was hired too late, just when the migration was about to begin.

So I ended up building the requirements specification, the business process documentation, the test case templates, and the go-live checklist, because if I didn't, nobody would.

There's a similar problem on the technical side. An experienced developer who's strong in one stack can usually pick up a new platform by reading the documentation. Under normal circumstances that's fine but a migration project doesn't give you the luxury of a learning curve. You're already juggling a whole bunch of unknowns. Figuring out an unfamiliar platform on top of all that leads to delays, wrong decisions that have to be unpicked later, and problems that don't surface until you're about to go live.

Business Analysis Is Boring. It's Also the Most Important Part.

Here's something I learned very early on doing site migrations for businesses. There's more at stake than for a hobby site so before anyone writes a line of code or designs a single page, someone needs to sit down and understand how the business actually operates. How do orders flow from the website through to fulfilment and accounting? What happens when a customer modifies a subscription, or requests a return, or changes their payment method? For a content-heavy site, the questions are different but equally important: how does content move from draft to publication, and what integrations feed content to apps, newsletters, or syndication partners? What are the dependencies between systems, and which ones are hard blockers for going live?

This is business analysis, and it's not something most design agencies do because it's not really their job. Their project managers are, quite rightly, geared towards managing creative output, not mapping data flows between an ERP and an accounting package.

There was one migration where the client's finance manager had flagged a hard dependency: the invoice consolidation between the ERP and their accounting software wasn't ready for the new platform. Without it, they couldn't record sales correctly and this would be a complete blocker at go-live. This fell through the gaps and went unnoticed. Again, I was hired too late and only found it because I sat down with the finance team in a discovery session. I asked boring questions about how they actually do their job, then documented everything.

I say boring deliberately. One thing's for sure: migration work is genuinely unglamorous. Agencies take it on because they want the fun creative work. Migrations are about spreadsheets, data mapping, test cases and checklists. It needs a methodical, detail-oriented mindset, rather than creative genius. Of course, the flashy design work is important as that's what customers see, but it's really not the core of a migration project. The core is making sure that everything underneath still works when you flip the switch.

Going Live Is Not "Take the Site Down for a Bit"

So it's time to go live. I've lost count of how many times someone has suggested taking the site down for a period during the switchover. Put up a holding page, swap everything over, bring the new site up.

This works for a brochure site. A mature e-commerce platform with active subscribers, daily transactions, and payment processing is a different beast. Taking the site down means customers can't place orders, subscriptions don't renew, and the business stops generating revenue. For a news or publishing site, downtime means missed deadlines and broken feeds to syndication partners. And if the switchover hits problems (you can't guarantee it won't, no matter how well you plan), "a few hours" can turn into days unless you have a rollback mechanism.

This is why I plan different go-live scenarios for every migration. Usually there's a hard switchover and a phased approach where both platforms run in parallel during the transition. The phased approach works like this: the new site is built and tested on staging. We then do an import of historical and current transactions while the live site keeps running. A final delta migration captures any content or orders that came in. Then a DNS cutover switches traffic to the new site with no interruption. If something goes wrong, you roll back. The business keeps running either way.

Most of the projects I work on end up going with some version of the phased approach, because when you actually sit down with the finance and operations teams and walk through the implications of downtime, nobody wants to take the risk of a hard switchover.

It's not just operations and finance you have to factor in. Marketing will often have planned a campaign around the relaunch, with email sequences, social media announcements, and partner notifications all timed to a specific date. Customer service needs to know what's changing and when, because they're the ones fielding calls from confused subscribers. Even the fulfilment team needs advance notice if order processing is going to look different on the new platform.

A go-live plan that only involves the developers is one that's going to cause huge problems.

Coordinating the Moving Parts

Here's a question that often falls through the gaps: who's responsible for coordinating everyone? What I usually see is the agency assuming the client will do it, and the client assuming the agency will do it. However, a migration for a typical business has the design agency, the platform vendor, one or two third-party integration providers, maybe a specialist for payment token migration, and the client's own team. Everyone's working to different timelines, different priorities, and a different understanding of what's in scope.

Design agency project managers are good at managing creative workflows. They track design approvals, development sprints, and QA cycles. But coordinating a migration is a different discipline since you're not just managing one team's output. You also have to track dependencies across multiple independent vendors, any one of whom can block the whole project.

For example, the ERP provider might need the new platform's API credentials before they can start testing. The payment migration can't happen until the subscription system is configured. The accounting integration needs to be verified before finance will sign off on going live.

Some of this is sequential while some has to run in parallel. If nobody's responsible for tracking how the pieces connect, one delay can stall the whole project. I've seen this happen many times.

For example, there was a time when the agency PM was tracking their design milestones while three integration workstreams were running completely independently with no coordination between them. Everyone was doing their job well, but in silos. Again I was hired well after the migration project started (notice a pattern?) so I needed to centralise everything into a single project management system. That way, when an issue came up in one workstream that would block another, I could flag it before it caused a delay rather than discovering it two weeks later.

And the content migration itself is iterative. People assume you run it once and you're done, but it rarely works like this for a business-critical migration. In practice, it takes multiple iterations to get right. You run a sample, find edge cases, adjust the processes, then run it again. The client's own content editors need to be involved in quality assurance because they know the nuances of how the content should be structured in ways that no external consultant ever will. It's a back-and-forth process that takes patience and attention to detail.

Why It Keeps Happening

I've seen two different agencies attempt the same migration, one after the other. Months of work, tens of thousands spent, and both hit the same wall. The design work was solid but nobody owned the integration layer.

When two good agencies hit the same problem on the same project, that's a structural problem. The good news is it doesn't have to go down this way. Agencies that recognise the gap early and bring in the right expertise for the integration side end up delivering better projects and keeping their clients happy.

Before You Start: What to Check

If you're a business planning a migration, or an agency about to take one on, here are the questions worth asking before anything gets signed.

For business owners

#	Question	Why it matters
1	How many third-party systems are connected to your current platform?	More than two or three and you're looking at a systems integration project, not a website redesign. The risk is in the connections, not the pages.
2	Does your agency contract cover back-end configuration and integrations, or just design and front-end build?	If the contract says "design and build" without specifying integrations, nobody owns the plumbing. Clarify this before work starts.
3	Has anyone mapped your business processes onto the new platform?	How do orders, subscriptions, returns, and payments actually flow through your systems? If nobody has documented this, critical dependencies will surface mid-project.
4	What's the go-live plan? Is anyone suggesting "take the site down for a bit"?	For active e-commerce with subscribers and daily transactions, downtime means lost revenue. You need a cutover plan with a rollback option.
5	Who is coordinating the work across all your vendors?	If that's not clearly assigned to a named person, it's not happening.
6	Have you involved finance, marketing, operations, and customer service in the go-live plan?	Finance needs accounting integrations working. Marketing has campaigns timed to launch. Operations and customer service need to know what's changing. If any of these teams are surprised on go-live day, you have a problem.

For agencies

#	Question	Why it matters
1	How many third-party integrations does the client's current platform have?	More than two or three and the project is bigger than a website build. Scope accordingly.
2	Is back-end configuration and integration work in your scope?	If it isn't, say so clearly in the contract. "Design and build" is ambiguous enough to cause problems later. Specificity protects both sides.
3	Does the client need business continuity during the switchover?	If the client has subscribers, recurring payments, or daily transactions, someone needs to plan a phased cutover. That someone probably isn't your PM.
4	Does your team have direct experience with the target platform's APIs and back-end?	Front-end design skills don't transfer to API-driven integration work. If your developers are strong in WordPress but the target is BigCommerce or Shopify Plus, you probably need a specialist.
5	Do you need a systems integration partner?	Bringing in someone for business analysis, integration work, and vendor coordination lets your team focus on design and build. It protects the client relationship and it protects yours.

What It Looks Like When It Works

When a migration project has the right structure, what the client gets is straightforward: a complete picture of their system before any work begins; a clear scope that everyone has signed off on; a go-live plan that protects revenue; and a single point of coordination across all their vendors. The agency gets to focus on what they're best at without being blamed for integration failures that were never in their scope.

That's what I provide on these projects. The article you've just read is basically my job description and sometimes it requires telling people things they don't want to hear. That once meant recommending the client terminate the project entirely. They kept their existing platform and their active subscribers, and avoided pouring more money into a project that wasn't going to succeed. That recommendation was harder to make than it sounds because I was being paid to oversee the project. Not only are you telling a client who's already spent tens of thousands that the best use of that money was the lesson it taught them, it also meant money out of my pocket. But it was the right call, and they agreed.

Get Someone in the Room on Day One

If there's one thing I'd want someone to take away from this article, it's this: bring in someone to own the whole picture from day one. Right at the start, when the project is being scoped and the contracts are being written.

By the time the agency has been hired and the work is underway, it's too late. The structural gaps are already baked in.

That person doesn't have to be a specialist migration consultant but at the very least, it should be an experienced project manager. Someone who understands multi-vendor coordination and systems integration; someone who's going to map the data flows and business processes before anyone starts designing pages. If you have that person in-house, great. If you don't, that's what I do.

If you're a business looking at a migration with a serious integration layer, have a look at how I handle these projects or the process I follow. If you're an agency and you'd rather bring in someone to handle the business analysis, integration work, and multi-vendor coordination while you focus on the design and build, I work that way too. I'm based in London and work with clients and agencies across the UK and internationally.

Common Questions

Why do platform migration projects go wrong?

It's usually not the agency's fault. Design agencies get hired for the website but the integration layer underneath (payment gateways, ERP connections, subscription management, accounting feeds) needs to be rebuilt too. When the contract doesn't specify who owns that work, the project is already underway by the time the gap becomes visible. The most common pattern is that nobody with systems integration expertise was involved when the project was scoped.

What systems need to be migrated besides the website?

A typical e-commerce platform migration involves five to ten connected third-party systems. Payment gateways (Stripe, PayPal), subscription management, an ERP for fulfilment, accounting integrations, marketing automation tools, and more. Every one of those connections has to be rebuilt and tested on the new platform before you can go live.

Do I still need a design agency for my platform migration?

Probably yes. Design agencies handle the visual output well: wireframes, mockups, page templates, front-end code. But you also need someone who understands the business processes and systems underneath, and can coordinate the integration work across vendors. These are different disciplines, and the best results come from having both covered.

How do I know if my migration is too complex for a design agency alone?

Count how many third-party systems feed data into or out of your current platform. More than two or three and the risk isn't in the page design, it's in the integration layer. If you've got payment gateways, an ERP, subscription management, or accounting feeds connected to your platform, you need someone looking at the whole system.

I'm an agency. How do I avoid this problem on migration projects?

Be upfront about scope from day one. If the project has a serious integration layer, flag it early and bring in someone to handle the business analysis and systems integration side. It protects your client relationship, keeps the project on track, and lets your team focus on the design and build work you're best at.

Why can't we just take the site down during the migration?

For a brochure site, brief downtime might be acceptable. For an active e-commerce platform or a high-traffic content site, taking the site down means lost revenue, missed deadlines, and disrupted customers. Go-live needs a cutover plan that accounts for business continuity, with input from finance, marketing, operations, and customer service, not just the development team.

When should I bring in a migration consultant?

At the very start, when the project is being scoped and contracts are being written. Most migration problems are structural gaps that get baked in early. By the time the agency is hired and work is underway, it's much harder to fix. If you can't hire a specialist, at the very least bring in an experienced project manager who understands multi-vendor coordination and systems integration.