Migrating to Shopify Plus: The 2023 Definitive Guide

With so many brands needing to scale quickly due to increased demand and the need to simplify operations and reduce focus on unnecessary technical overheads, the Plus proposition has become the de-facto for DTC brands in particular looking to grow revenue and their bottom line.

In this guide, we're aiming to cover all of the key areas of consideration for migrating to Shopify Plus, allowing for larger and more complex implementations.

Why do companies migrate to Shopify Plus?

There are so many reasons for brands and retailers assessing and moving to the Shopify Plus platform, but the most common ones, in my opinion, are:

Agility

The biggest reason people move to Shopify Plus, in my experience, is being able to get more feature development and optimisation efforts delivered within their budget. This is a real game changer for brands and comes as a result of the following.

Technology partner and developer eco-system

The Shopify App Store is what really separates it apart in this area, with so many feature-rich and constantly improving technology partners making it far quicker and easier to achieve new functionality. The apps and technology partners are also typically open for further customisation (via APIs and integrations with other third parties). And the SaaS infrastructure also means they’re always improving. This approach allows brands to achieve a high percentage of their requirements at a low monthly cost, rather than investing time and budget into building something bespoke that then won’t be progressive.

This approach really helps brands to innovate within budget and remain agile around new features. Examples of these features could be quizzes, marketplace functionality, different levels of personalisation, trade-in and so much more.

Another major benefit is the number of highly capable agencies in the Shopify Plus space. They are capable of building very strong themes and handling other key aspects of a project and on-going program of work.

A lot of the agencies have come from a design and front-end background, so they’re a bit more focused on this area, which is a real benefit for the average merchant looking to migrate over to Shopify Plus. The volume of good agencies makes things a lot easier for merchants and you then also have a lot of more specialist developers focused on other key areas (such as app development or specific types of integrations) that can support where needed.

Overall, there’s a real shift towards value here compared to some of the other platforms where there’s a lot of expense around maintenance and other professional services required to deliver projects.

The focus on configuration vs. development

One key difference with Shopify compared to other platforms is their commitment to building more functionality into configuration and reducing the need for development, beyond the front-end and particularly complex functionality. Areas such as payments, adding additional currencies, and checkout options are managed via admin configuration, saving a lot of money and time and allowing teams to be more agile with testing things like international features.

Underlying simplistic architecture

The reduced need for back-end developers and technical inputs generally, restricted access to the platform via APIs, and unrivaled documentation make new feature development far more efficient in terms of time and cost. The overall experience for the client is also then so much cleaner, as a result of fewer bugs and reduced scope for issues.

Re-focusing internal resources

As already touched on, the core areas of focus with Shopify Plus are quite different to other platforms and there’s less need for management of maintenance and major technical projects (such as upgrades). One of the biggest benefits for a growing brand, in my opinion, is being able to focus teams on the end-to-end customer experience, brand development, retention activity, and new customer acquisition. Again, for our average brand moving to Shopify Plus from one of the monolithic, more legacy platforms, this is both a driver and a key benefit.

Scalability

Shopify Plus is proven to scale in a number of different ways, such as with short-term and long-term increases in demand, concurrent users, and transactions. This scalability is also evident as more complexity is introduced into the business and as the remit of the business is broadened (e.g. new markets or channels). Other platforms can also scale, but with a lot more inputs and investment, as well as internal capacity.

Reduced OPEX costs (and distribution of budget)

I’ll dig into this more in the total cost of ownership section of this guide, but overall, the OPEX (operational expenses) costs around Shopify Plus are typically lower (in many cases, much lower) than the obvious and most common competitors. I’ll go into specific line items and how you’d actually compare different models later on.

In addition to this, the percentage of development budget focused on new features and areas designed to drive incremental revenue is much higher, with very low spend on maintenance and support elements.

Features, innovation and newness

Another area that can often drive people to start reviewing Shopify Plus or even triggering the move is the cadence of new feature releases and then also the amount of innovative or unique features and offerings they’re releasing.

In 2022, there was a huge amount of new features and functionality within Plus, with obvious examples including the introduction of Hydrogen and Oxygen, Shopify Audiences, improvements to Markets, the introduction of marketplace kit, Shopify Functions, the new B2B offering and various others.

Recent examples of innovative or new-to-market features introduced have included various aspects of social selling (such as Pinterest, YouTube and TikTok), ShopifyQL, the acquisition and integration of Dovetale, various levels of web3 integration (NFT morning, tokengating, crypto payments) and lots more.

Ease of use

Another element that has always helped Shopify and Shopify Plus is the intuitiveness of the admin UI—with constant testing and improvements to usability and positioning of features and functionality. This may seem small, but admin users are always citing this and I frequently hear senior stakeholders talk about how much cleaner the Shopify and Shopify Plus admin looks following platform demos.

Building the business case for Shopify Plus

Most commonly, internal teams will need to build a business case to get a CAPEX spend signed off. The points mentioned above are some of the most common things to reference, along with a breakdown of costs. The points following this section will help with building a budget, but often you’ll want to include some of the following when building a business case for replatforming:

• Cost comparison over three years (new tech stack vs existing tech stack)

• Contributions to growth of the business (new channels, key bottom line drivers etc)

• Additional justification of any sunk costs (detailed out ideally)

• Time savings and any other savings for the wider business

• Any potential security or compliance benefits

• Any other forms of de-risking the business

• Any other net benefits (better integrations, CX improvements, internationalization wins etc)

• Approach to project (counter any arguments around resource constraints, detail project team etc)

• Case studies from other brands (ideally ones that the business respects and looks up to)

This is high-level, but the above and the detail below should help to put together a compelling argument and also help for planning and countering any key arguments.

Assessing the total cost of ownership (TCO) of ecommerce migration

Doing a TCO (total cost of ownership) assessment with different platforms is always tricky, with variables around cost models and different areas that require differing levels of investment. Shopify Plus is often cited as being quite hard to assess, as there are a few areas that aren’t the same or comparable with other platforms.

The core costs are pretty simple, with the license being either the flat $2k per month or the GMV, varying by month depending on volume. The build costs are then typically pretty straightforward, with either a fixed cost or variable estimate defined following a discovery phase. There are, however, some costs that are a bit harder to compare and review. The main areas that fall into this category include:

• App costs (plus per store) - third party app providers will typically charge on a monthly basis, which can really start to add up as you use more and more expensive providers. This isn’t hugely different to a lot of other platforms, but is often commented on by platforms where modules are typically charged for on a one-off basis or where customisation is typically handled in a bespoke manner by developers. I personally love how the apps side of Shopify Plus’s eco-system works, due to the progressive nature of the solution (constantly adding new features and integrations). The only other variable is most apps charge per store / instance, but this is also often negotiable if you broach pre-signing with the vendor or contact them directly. This can be negotiated usually.

• Payments - this is definitely the biggest variable here, with Shopify Payments being the primary route for most and then merchants paying an additional 0.15% processing fee should a compatible third party provider be used. Generally, Shopify Payments is fairly competitive around costs, but the simple nature of the costing can cause a lot of confusion when comparing against other providers, who split out areas like interchange fees and also merchant services fees and authorisation fees etc. I regularly have conversations with finance teams who have wrongfully decided Shopify Payments is very expensive, due to this nuance in how fees are represented. Markets Pro is another new variable here.

• Licensing variables (multi brand) - this isn’t applicable to all, but we regularly find we need to factor in costs around multi-brand agreements, as different brands will typically trigger a new agreement. This is always worth a conversation with Shopify, but often there will be additional charges here.

• Support and maintenance - often, when comparing platforms, there’ll be line items against one platform for things like hosting, version upgrades, support / maintenance hours, and so on, whereas this isn’t needed with Shopify Plus as it’s handled at a platform level and provided as a SaaS. Although the majority of Shopify Plus users will have a development retainer, most will use those hours primarily for new feature development, and optimisation efforts.

To summarise, the main costs that need to be allowed for when approaching a Shopify Plus migration project are:

• Theme design and build (agency)

• Data migration costs (usually agency)

• Any custom app work (agency or separate third party)

• Any consulting or interim needs (optional - e.g. PM, solutions architect, BA)

• Integrations (often separated out to a specialist)

• Testing (optional)

• Analytics (optional - but many agencies won’t be specialists, so you’ll want an independent analyst)

• SEO direction & support (optional - but you’ll likely want a specialist)

• Third party and app costs

• Any change in payments rates (including FX fees

• Contingency budget for any change requests and other expenses

You probably want to map out the above and build a three year model with a comparison against your current approach and tech stack. Sometimes you’ll have more complex variables like a reduction in headcount or split budgets.

Recommended steps for de-risking a Shopify Plus migration

A replatforming or migration project is always high-risk, no matter what people tell you. This said, there are a lot of steps that can be taken to reduce risk in different areas, with the following being some of the big ones.

Build out your initial requirements

When you’re approaching potential development partners (and even third parties in some ways), it’s important that you’re providing enough detail for them to give you an accurate time and cost estimate. I often see projects go into discovery with one cost estimate or timeline and come out with something very different - leading to frustration, a loss of time (in moving to another provider) or the project not being deemed a success (due to late delivery or budget overages). This is often the client’s fault though, or at least they didn’t provide clarity in places and left assumptions that led to an inaccurate estimate.

We always suggest providing enough detail for a team to be able to accurately estimate the project, leaving as little as possible unknown. The ideal scenario is that if items are left fairly open to T&M or post discovery estimates, they’re the smaller areas that are not going to add significant time based on variance. This won’t always be the best approach, but it usually helps to de-risk. You can always vary the scope in discovery and you should definitely remain open and flexible. But the goal is ensure that you’re able to deliver a scope you’re happy with within budget. If your budget is tight or fixed, this is even more important.

Here are some key tips for building an initial set of requirements to approach agencies with:

• Make the role you want them to play clear (e.g. role in integrations or data migration)

• Quantify any data you want them to migrate or own (e.g. number of orders or customers)

• Detail all complex areas of the project (this is key - anything non-standard and unique to your business)

• Detail any integrations requirements (but make their involvement clear - e.g. advisory services)

• Detail how areas like international or customer accounts work currently and how they need to work (number of stores or scope of account is often a variable)

• Try and provide any info on items you know you’re looking to improve (e.g. filtering or gift cards)

• Provide details around any known third parties and enough detail for them to have a view on new ones.

• Potentially involve a specialist to help get to this point (to ensure the brief and scope is sufficient and meaningful)

• Make your team clear (so they can suggest additional bits where needed)

The overall goal here is to get an accurate response. This doesn’t mean the fastest or cheapest, but does require clarity around cost and timeframe. Also, this upfront detail isn’t the be all and end all, particularly if you have a relatively open budget or you’re happy to be flexible. But, it can massively de-risk against on-time delivery and on-budget delivery.

Think about internal deliverables and capacity

One of the biggest routes to de-risking is ensuring that you have the right team and skill sets to deliver the replatforming project to the highest possible standard. Most of the projects we work on will have a team made up of internal and external resources, with us often filling some or all of the external inputs.

Really, a replatforming project requires the following, with some variables depending on size and complexity:

• Designer(s)

• Developers(s) with varying skills requirements

• Project manager or owner from each external team (e.g. agency, integrations provider, SEO agency, etc.)

• Overarching project lead, project manager(s), product owner(s), and/or program manager— this person or people will own the combined scope, delivery, and budget of the project

• Execution resources (usually internal) focused on areas like configuration and different levels of data importing

• Internal or external testing resources (or combined)

• SEO input (usually external)

• Analytics input (usually external)

• Solutions input (usually external but not always needed) to govern key technical areas and collaborate around approach to key aspects

• Business analyst (very rarely needed beyond agency or internal resource, but very useful)

This team will massively vary depending on the size of the project and the skills you have via your internal team or external agency.

Building out the internal deliverables as early as possible is key to having a successful project plan and being able to commit to an overall timeline. Most of the projects that we’ve seen delayed have been because of the internal team, rather than external.

Some of the key internal deliverables include:

• Front-end testing and user-acceptance testing (UAT) - it requires a lot of time to do this properly. You’ll want as many people as possible to help and you’ll need to build out test scripts, source physical devices (dictated by those most important to you). You can outsource higher proportions of this, but you always want to do some level of testing internally. I’d usually recommend getting test scripts built fairly early based on the initial documentation and design. I’d then start sourcing people that could help internally and then you’d want to divide and conquer. You’ll always find bugs even with the best agency in the world, plus it gives you a higher level of assurance around the site.

• Integration testing - same as above, but you’ll need more specific stakeholders to help. It’s key to get the test scripts built out based on the initial documentation, which will require key inputs from your finance team (e.g. discount reporting, handling of gift cards, loyalty points. etc.) and IT operations. The systems involved here will vary, but it’s important to get this separated out and done properly, end-to-end. As with some of the other areas, the quicker you get this done, the less risk and the more time you have to perfect other areas.

• Analytics and tracking testing - you’ll likely outsource the execution work here, but you’ll need to test all of the tracking and analytics for your new site. You’ll likely have minor bits that may require tweaks post launch, but the core should be tested to ensure proper tracking and that you’re able to assess the success of the launch.

• Data migration testing - ensure you have time to test data that’s been migrated, with a focus on any balances, customer properties, and orders.

• Management of projects - This is the big one. Depending on the complexity and scope, you may want to outsource this to a specialist again. If not, you’ll just want to ensure you’re documenting as you go and you have a really strong project plan built out for all of the different third parties as there’ll be lots of dependencies.

• Configuration of Shopify - although mostly straightforward, it’s important to plan the configuration tasks with things like the payments application, tax rules, shipping rules and various other tasks that sometimes have dependencies. This can also become bigger when you have multiple stores and business entities.

• Redirects (possibly) - this is one of the most important tasks when replatforming, but it doesn’t always sit with the internal team. This is a big task when done properly, so it’s important to build into your project plan with ample time for testing.

• Catalog build - there’s lots more detail around this in this guide, but this is probably the biggest one, when done properly (architected to keep things efficient and for long-term effectiveness). There’s a lot of work to be done here and setting up collections properly also takes time.

• Launch planning (inputs) - depending on your team, you’ll have varying inputs around things like DNS management and setting up of domains, both of which need to be planned. You then also have things like sending reactivation emails for customer accounts, ensuring all tracking is working. I wrote this guide a while ago which is useful for planning a Shopify launch.

• Planning any reporting bits - another area that can be overlooked is business reporting, with people not realizing that they need to re-connect certain reports or Shopify doesn’t natively support certain reports (e.g. a discount report). This is something that, again, needs to be planned ahead of a launch and assigned to internal team members.

Think about who is best to deliver key parts

As already touched on, for larger or more complex projects, the days of just selecting an agency and moving forward have arguably gone, with the ideal project team comprising a number of key, specialist inputs. Depending on the brand and the scope, we will sometimes suggest a separate creative influence (if the scope is broader or the agency isn’t best placed—definitely not always needed), an integrations partner (to ensure that this is delivered in the best way and is future proofed), an SEO specialist, an analytics specialist and then potentially some level of testing support. Another area that I mentioned above is doing key areas of the product and catalog migration internally to assure quality and ensure the data is built how you want and not how it has been in the past.

The more you de-couple key areas and bring in experienced specialists, the less risk there is in that area, and also in the delivery of the overall project. The only one comment I’d add is often you’ll need to allow for a buffer. You’ll need to get the communications right in places, which can end up increasing the timeline, but it’s typically worth it and reduces risk.

The biggest one mentioned above is integrations, where a business can really benefit from handing over to a specialist platform or company. Using an integration platform means that there’s usually some level of pre-built feature-set and integration available and they’re also only focused on integrating systems in the most progressive way possible. Although it’ll often cost more, I’ve found that these companies are a lot better at scoping this area, testing, and they tend to push best practice and be more proactive around improvements. Moving data around is so important and having a service that can own this, unify that data, add in logic (e.g. stock syncing between two stores that use the same stock file or some level of queueing) can be really beneficial.

Get your data in early

Probably the best bit of advice I can give anyone working on a project looking to de-risk is to get the data in early. The most important bit here is the product catalog, as that’ll usually use a lot of internal resources and also have a lot of dependencies (e.g. building out of collections, testing and configuring third parties, VMing of collections, various levels of testing etc). If you’re able to get your catalog built early, it’ll allow your team to focus on other areas and also just get ahead.

The same principle does apply with customers and orders, but there’s slightly less benefit in getting all of it in straight away, as chances are you’ll be doing a delta import later on anyway and there aren’t the same level of depencies. The same applies to the likes of gift cards, discount codes, reviews etc.

As a general rule of thumb across, getting data in and finished off early reduces stress and fraction towards the end of the project when there will be other priorities.

Allow time for getting your catalog right

Getting your product catalog built well is a key part of a replatforming project, but there are nuances with Shopify Plus that don’t necessarily exist with other platforms. Some of the key steps to getting this right that I’d recommend include:

• Ensure you’re at least having big inputs on this internally - it’s very rare for an agency to be best placed or right to take ownership of your catalog—as it’s never a like for like and lots of other areas can impact how data is structured in Shopify. Lots of agencies can write scripts to help with the import, but getting this right in Shopify takes more thought (if you want to perfect things like smart collections, improve filtering, and get the most out of third parties). This isn’t just a Shopify thing. A migration represents the perfect opportunity to perfect and improve your catalog.

• Build your master doc - initially, we suggest mapping out all of the required tags and metafields in order to build out content for all templates, build your smart collection logic (to populate the collections based on rules), allow for theme logic requirements, populate data feeds, allow for all apps and third parties and then anything else needed (e.g. reporting or segmentation). From here, you can have a level of documentation (for other team members) and then you can start to populate the fields in a spreadsheet.

• Manually map and build the data - we often suggest doing the next piece internally, to ensure that everything is perfect (it’s also good for your team’s education). We’d map data from the source file into columns in a spreadsheet and then delegate out responsibility for any new fields (e.g. a metafield for a new content slot on your PDP). If you have a huge catalog, you’ll probably want to do a bit of a hybrid approach to programatically map some fields and then go from there.

• Import - From there, we’d then change the headings of the metafields, concatenate the tag values and then import into Shopify (we use Matrixify, which we’d recommend). Another step for de-risking is to do one perfect product first, to ensure everyone is happy and also all the data is working as expected.

This may sound cumbersome or unnecessary, but the catalog is very important and there’s a layer of business reviewing that needs to be factored in. The value of re-thinking the data and having a very clean tagging taxonomy for example is also often not considered.

Ensure there’s sufficient focus on SEO

Although often overlooked or considered secondary, SEO is one of the most common causes of a failed project. With so much risk associated with migrations anyway, and so many key considerations that need to be factored in, SEO can easily be overlooked to your company’s detriment. Although Shopify has got loads better with the technical SEO side, there are so many tasks and deliverables that need to be planned and accounted for in order to minimise the impact of a migration on visibility and organic revenue.

Key areas that need to be considered here include:

• Data migration - it’s key to migrate core data in the same way to avoid change, such as the long description, supplementary content and then of course metadata. Although the front-end will likely change, the actual content across the site will ideally remain the same to avoid Google and other search engines seeing large amounts of change. This is a key area that needs focus from multiple stakeholders and it should also be factored into the testing plan.

• Use of JavaScript - it’s still best practice to allow core content to render without JS. I regularly see themes built that are rapid but most content is loading in via JS, which many search engines still struggle with and can still cause issues with Google. The most common JS-related issue I see though is the product grid, with some solutions offering things like personalisation as a result of loading in the grid via JS in the browser. It’s important to make sure that you’re optimizing as much as possible here.

• Hreflang - hreflang with Shopify can be very complex, because you’re usually working with multiple stores, which can have nuances with catalogs. If you have multiple DCs or warehouses, chances are a blanket logic won’t work. You should be ensuring handles are the same across all stores for the main base logic and looking to build in the ability to overwrite hreflang references where needed (if collections or products aren’t on all stores, for example). This can get more complex if you’re using a combination of markets and expansion stores.

• Changes to templates and navigation - it’s fine to make changes here, you just need to understand the risk from an SEO perspective. If you quantify the risk and are happy with it, you can do what you want around changes here. But, if your primary goal is to reduce impact on organic visibility (if you’re heavily reliant on non-brand organic traffic), then you’ll want to be careful. Major changes to content and internal linking can have an impact on short-term and long-term visibility.

• Performance - The other obvious one is performance and ensuring the site is optimized for core web vitals. This needs to be governed through the project and, again, core web vitals should be part of the testing and UAT phase.

Overall, I’d say it’s good to quantify the level of risk associated with SEO during migration, and just balance out the cost–benefit when you’re making significant changes.

Keep key stakeholders involved and informed

There are so many important stakeholders in a replatforming project. I could write a guide on the management and communications required alone. But there are certain stakeholders that you’re going to need to be on-hand at key points to assure the project. The ones we typically need key inputs from are:

• Finance - key inputs around payments, reporting and integrations.

• IT - key inputs around integrations and technology in general (as well as things like domains and DNS for launch).

• Marketing - key inputs around reporting and tracking.

• Creative - Key inputs around, design, comments and the front-end CX in general.

• Merchandising - Key inputs around inventory, reporting and product.

• Operations and logistics - Key inputs around integrations and CX.

This will vary by project and business, but the above usually makes sense and is fairly consistent.

I’ve kept the next section—selecting an agency—isolated, but it’s also a massive part of de-risking a project.

Selecting an agency

If you’re outsourcing the build or even just parts of it, selecting an agency is going to be one of the key influences on the success of your project. There are lots of things to consider here and everyone tends to have different views on what makes a good partner. Here are some things to look at and some bits of due diligence we recommend from our experience.

Look at their work organically

It’s always good to judge agencies based on the quality of their work, be that the front-end of their sites or complex features that have been delivered. You can then delve more on specifics as you talk to them.

Assess project team

The project team is often the most important part. The goal is to have a very capable project lead, PO or PM, a designer (if applicable) that resonates with the brand and business, and developers that are able to deliver key aspects of the build. You won’t always have full visibility here, but the main project manager and account manager roles are usually key, as they’ll be your main point of contact. The other one would be the people leading the discovery, which is key, and something else to focus on during your assessment.

Where do you sit?

Another important area is where you sit in their client roster. Again, this doesn’t always matter, but you often see brands end up getting a lesser service as a result of being the smallest client. Equally you may not want to be someone’s biggest client if you want to benefit from ideas from other similar sized businesses. Again, this can depend on what you actually need from the agency, with some wanting them to deliver development tasks and others wanting a true partner for growth.

Beyond launch

Another thing to always consider and do due-diligence on is how things work and costs beyond launch. This will help ensure that you’re clear and aligned with expectations, budgets, preferred ways of working, and availability for assistance.

Take up references (direct and indirect)

I always like to take up references that are given and then also get independent feedback from anyone else that has worked closely with the agency or previous clients. This level of due-diligence is always important, and usually gives you tips for how to get the most out of the agency.

Gauge capacity

Because of the popularity of Shopify and Shopify Plus at the moment, one of the biggest variables around the quality of work and on time delivery of a project is capacity, with many agencies struggling to resource projects or allow for any changes to scope. This is always hard to read and fully understand, but it’s always worth asking about and just getting a bit of verbal reassurance.

Governing discovery and further de-risking

Again, there are always variables here based on how the agency prefers to work, how fixed your budget is, and the timeline for the project. My advice going into discovery is the following.

Avoid major unknowns

Assuming there’s been a CAPEX budget signed off, I always say that you should look to give an agency enough detail to provide a considered quote, but you should then remain open going into discovery. My preferred approach is to get a fixed quote (or close to one) for a scope, but that scope should then be open based on collaboration with the agency’s team.

So, as an example, you may have a $100k budget and you’ve outlined in detail what you need to achieve and base level functional requirements for key areas. But you may be able to go and ask for more budget if there’s rationale or you choose to extend the scope. The key is having protection against what you need to deliver within the allocated budget, but you then may be open or choose to invest more based on the discussions with the agency.

The goal is to avoid too much time on high-level estimates, as this can lead to exceeding budgets and then also giving the agency enough context and detail to accurately quote. Both sides can lose out here and the relationship can be put under strain as a result of a lack of detail.

Think about administrability

When you’re going into detail through the discovery - you should have one eye on administrability, as some third parties or approaches to functionality may cost your internal team significant amounts of time. The goal should be to give your team freedom to trade the site and represent the brand as well as possible, whilst also being able to import / export where possible, avoiding duplication of data across tags and metafields.

This may sound strange, but pushing something into a private app or a third party can make things a lot harder to manage. Choosing third parties that don’t support multiple stores (e.g. a search and / or merchandising solution) can also cost a lot of time.

Architecting for multi-store

This is one of the biggest variables for large Shopify builds, with the number of stores having a big impact on overall cost and complexity, but also overheads for internal team members. This is, again, something you’re better off having a view on before going into discovery, just to avoid shocks through the process.

The biggest things that lead to additional stores today (as many of the issues have now been resolved) are inventory sources / DCs (as you cannot currently assign locations to different markets) and pay-outs (being able to pay into separate bank accounts), with some other considerations around catalog and local trading.

The other consideration here is now Markets Pro, which can also help with some of this, but there’s a bigger discussion around where that fits and the additional costs.

Final thoughts

Migrating across any platform can be a complex process, but with the right planning, de-risking, support and expertise, a replatforming project can be a success - and can be a rewarding exercise for any brand.

If you need any support in your replatforming management and want to explore how we can help, then get in touchaunt.com/contact/.