Migration to Shopify step by step: plan, data, testing and launch

Episode recorded in Polish (English subtitles available on YouTube); this is our edited English translation. Released on 9 May 2023, so Shopify features reflect that time: Shopify Scripts have since been retired (replaced by Shopify Functions), the Transporter app for importing order history no longer appears in Shopify's documentation, and since March 2025 Shopify Payments has been available in Poland, including BLIK, so the argument about a better fit for the Polish market is weaker today. Today we migrate data with our own AI-powered system, which moves data faster and more safely.

When does the idea of migrating a store come up?

Tomek: Hi! Today we're taking on a big topic: store migration. We'll focus on migrating to Shopify, of course, but the process itself is fairly universal, whatever the technology. We'll try to tell you how to avoid mistakes and slip-ups and how to reduce the risk that comes with the process. Let's go. Hi, Maciek.

Maciek: Hi, Tomek.

Tomek: It's a big, broad and difficult topic, but let's give it a go. This will of course be a conversation about migrating to Shopify. Maybe let's start with where the idea of migrating comes from. When does it first come up for store owners?

Maciek: Sure. Before we get there, one quick introduction. We're talking about migrating to Shopify, but the process is general enough that the methods we'll discuss will let you migrate from any system to any other. They're universal, and I think the migration framework is very similar everywhere.

Tomek: Right, so let's think about when that thought appears, what triggers it and when an owner actually decides to take such a big step in their business.

Maciek: The first thing is definitely the technological limits of the old platform. That covers all sorts of problems with how the platform works: how long it takes to build features, implementation costs, problems with how individual processes run. In a word, as the business grows we naturally outgrow the platform we were on, or we simply want to move away from technologically outdated platforms.

Tomek: I'd add that growth often means expanding abroad, into European or global markets, and the platform doesn't fit those needs, because the merchant originally chose a typically Polish solution to operate in Poland. The business has grown, the owner has expansion plans and is looking for something more scalable. That comparison to outgrowing your current solution probably captures the trigger point best, when you start thinking about migration.

Maciek: It's a question of needs. We're talking about migrating to Shopify here, but we also know of cases where merchants left Shopify for Shoper, because in some respects it's better suited to the Polish market.

Why is migration seen as difficult and risky?

Tomek: Let's think about why the process is seen as so hard, complicated and in need of a lot of preparation.

Maciek: Above all, it's a high-risk process. A lot can go wrong along the way. It's an extremely stressful experience for the people involved, especially on the client side.

Tomek: Yes, because we're replacing the basic tool they've worked with for a long time with something they may not know, and which certainly has a huge impact on their business.

Maciek: It's worth expanding on that, because many e-commerce systems are monolithic. They form one whole, sit at the heart of the ecosystem, and all the tools are connected to that one central system. When we pull it out, we have to plug everything around it into the new system. A future answer to this may be replacing the monolithic architecture with what's commonly called composable commerce. It's a relatively new term for an approach to designing e-commerce systems where you pick tools like building blocks and assemble the processes you need. If you want to replace one thing, say you're on Magento and don't like how one process is managed, you don't have to replace all of Magento; you take out one block and swap in a solution that suits you. Search, for example.

What can go wrong in a migration?

Tomek: So let's ask the contrarian question: what can go wrong in a migration like this?

Maciek: Like with a heart transplant. Everything can go wrong.

Tomek: In my view, what e-commerce owners fear most is that we unplug something that has worked one way or another so far, plug in something new, and the moment of switching over or launching the new system can interrupt the whole business process. Business continuity can be disrupted, and in e-commerce what we care about is…

Maciek: …not ending up like that legendary government office whose website was open from 8:30 to 15:30, during office hours, and didn't work after that.

Tomek: Exactly. In e-commerce, customers have a bit more freedom in when they use the store. Above all I'd be afraid that what has worked so far stops working. I interrupt my business process, and that directly hits my sales.

Maciek: Absolutely. Either everything crashes and nothing works, or individual processes that are also critical break. Returns, for example, if they're handled differently, or search, filtering, integrations with particular tools or order fulfilment.

Tomek: On top of that, bear in mind that many businesses build their model on one very specific feature. Subscriptions, for example: they build loyalty, tie users to their product and store, and get repeat purchases. Imagine that after the migration that core feature stops working for some reason, or doesn't work as well as before. That's a very short road to failure and really big losses.

Maciek: Sure.

Tomek: From my perspective those are the biggest fears: that something bad will happen to my business, and what worked one way or another, and what I was used to, will suddenly stop working and I won't know what to do next.

Maciek: Another problem can be losing part of the data. That's a real risk too. The safeguard is of course a backup and keeping the production store running for as long as possible, even for a while after the new system goes live, until we're sure everything is fine and we no longer need the old system. The right approach to data migration is also key.

When should you start to be ready for Black Friday?

Tomek: I'll add bad timing. A migration usually takes several months, and the e-commerce year has specific events, such as Black Friday and Cyber Monday, when sales are highest and the business earns the most.

Maciek: Such an incomprehensible phenomenon.

Tomek: Yes, an incomprehensible phenomenon. I can easily imagine the migration to the new platform dragging on too long and it turning out that we don't make it in time at all…

Maciek: I have the feeling it's not that it drags on; it simply starts too late.

Tomek: Or it starts too late. Not knowing how long the process will really take means we'll be completely unprepared for a big sales event, because we'll have a new system we don't know well yet and that hasn't been tested.

Maciek: Exactly. That's one of the key problems.

Tomek: The worries and the risk will be huge then. And second, we simply won't be ready with the new store in time and will stay on what we had. We've put a lot of effort into building something new, but we can't show it off.

Maciek: That's probably the biggest warning: give yourselves time to do it well. When time is short, people work under pressure, nervously, in a rush, and things get missed. That's where the problems we've talked about come from.

Tomek: A tip for store owners planning a big migration who want to be ready for the crazy November period: the best time to start work on the migration is the first quarter of the year.

Maciek: Planning a new store launch a day or a week before the peak of the season is asking for trouble.

SEO, new systems and other risks

Tomek: Exactly. Maciek, I'd also mention something people think about less when planning a migration, because it's less a business issue and more a technical one: losing SEO rankings.

Maciek: OK.

Tomek: A really large share of stores build up their position in search, and building it organically takes months, even years. There can be a serious fear that SEO won't be looked after properly during the migration. And suddenly there's a very nasty surprise: the store drops by dozens of positions and we land on page two or three of the results. That translates very directly into the business, because revenue falls.

Maciek: I don't recommend it.

Tomek: I don't recommend it. We could probably list plenty more of these fears. What's more, every e-commerce owner has their own. As you said, processes are often very unique: a custom system of discount codes, even the notifications that handle the customer experience side.

Maciek: That reminds me: very often migrating to another platform means adding new tools. We might be introducing an ERP, a PIM or other tools at the same time. Those implementations can overlap or drift apart in time, which can complicate the planned process. So it's worth getting the order of these activities right.

How do you reduce migration risk?

Tomek: So let's move on to what to do to avoid these mistakes. We'll come to it in a moment: not everything can be predicted, but you can certainly minimise the risk and the worries that come with the process. Any key advice, Maciek?

Maciek: For me, the most important thing in planning this kind of process is having a migration plan and following proven rules, procedures or checklists you've developed. That's how we do it at the agency, at least. Of course, you can run the migration with an in-house team. But working with a partner experienced in this process reduces the risk, because you and your team might do a migration like this a few times in the whole life of the company, while a proven partner does it a dozen or several dozen times a year, so they have methods worked out. That's what we'd recommend, although we're biased.

Tomek: To sum up: work to a proven process, with a specific method and a specific action plan.

Maciek: Yes.

Tomek: And get good support from specialists who have more experience with it. So let's try to describe how we organise the migration plan and process at our agency for a typical client who wants to move to us. What do the individual steps look like? I think it'll be useful for everyone to see in what order…

Maciek: …and you can easily repeat it with your own team.

Tomek: Exactly.

The discovery stage: technology and UX workshops

Maciek: We recommend this way of working. We always start with workshops, a scoping session. On one hand they examine the current state, where we are and where we want to be, and on the other they sketch out a plan for getting from point A to point B.

Tomek: Let's expand on what goes into this stage, which we call discovery, the stage of getting to know the business. The goal is for both us and the client to clearly identify the current solution and the whole ecosystem it operates in. E-commerce is often one part of a whole system that handles sales, production, marketing and so on. So we split the workshops into two areas. The first is strictly technology workshops and identifying the client's processes, both on the e-commerce side and in the additional systems that make up the ecosystem. We then have to map those processes, that is, reproduce them in the new structure we'll propose.

Maciek: Exactly.

Tomek: As you said, we set the goal: where we are, where we want to be and what lies in between, the so-called gap analysis. What gaps we have in our processes and in the business, and how our solutions should address them. That's the technology part. But it's worth adding that a store migration is a very good moment to rethink the visual layer and the customer user experience. That's why in discovery we often run a second type of workshop, focused on the business and its customers. Maybe it's worth expanding on that.

Maciek: The operation usually takes so long and is so complex that it's rare for someone not to tackle this stage as well. It's a good moment for a redesign. Part of the UX discovery workshops for e-commerce is examining what has worked well on the site so far and what shopping habits customers have. We observe behaviour and look at qualitative and quantitative data. During research we track user behaviour with tools like Hotjar and review the statistics. That matters if only to know where traffic comes from, which pages it lands on, and whether it's mobile or desktop. There's a lot to examine. You can also add an audit of the current system to catch basic errors and address them later. We'll probably go into this in more depth in future episodes. But it's rare for a client to move the store with the front end one-to-one. We've had scenarios like that where really the only difference was a new checkout. Incidentally, I think we've mentioned that conversions doubled at the time.

Report, scope and roadmap

Tomek: Let's go back to the process and take the next step. We run the workshops, and the result is usually a report in which we write down all our observations and the results of the work and exercises. What's extremely important is that at that point we have the right scope of work agreed.

Maciek: On one hand the scope, on the other a roadmap: in what order things should happen, what we do now and what will happen after launch.

Tomek: Yes. This stage gives the client a lot of certainty, because they know exactly what to expect, what steps lie ahead, which tasks will need their attention or action and which we'll take care of. A clear vision and a transparent picture of what we want to deliver next.

Maciek: Often after this stage we can give a more accurate estimate, but that's a side issue. Does running this stage eliminate all oversights and risks?

Tomek: Definitely not. I won't be saying anything groundbreaking: e-commerce and the whole ecosystem are a very complex process, and unexpected situations or unforeseen obstacles will certainly crop up during the work. What matters is that the report and workshops minimise the risk, because at the start we identify as many areas as we can.

Maciek: We've never had a client tell us afterwards, "Listen, guys, we forgot to do the checkout." But it does happen that someone says, "Oh no, we forgot that we advertise on such-and-such network, or that we're integrated with some marketplace."

Tomek: That's right.

Maciek: Because it slipped through at…

Tomek: …at the discovery stage. Exactly.

First steps: setting up the Shopify environment

Tomek: So we have discovery behind us and we start the work. What are the first steps with Shopify? Where do we begin?

Maciek: As you said, we can start several stages in parallel. Design work can be under way, the development environment can be set up, and as soon as it's ready, work on importing products can start straight away. Sorry, importing data.

Tomek: Exactly. I'd like us to expand on those areas. On setting up the environment, an important point with Shopify: when we create it at the very beginning, we give the client access straight away to the target environment they'll be working in. That way they learn how it works and can get to know it.

Maciek: There's time to get familiar with it, and no training is needed after launch.

Tomek: Yes. We always run training tailored to the client before launch. But the admin isn't new to them at the time of the training, because they can work in it throughout the migration, which matters a lot when switching to something completely new. For the setup stage, let's just list what we do, because we base our migration processes on very detailed checklists, down to the smallest tasks at each stage. There are so many tasks that it's very easy to forget the most basic ones, and from the business's point of view they're just as important. That's why we use the checklists we've built.

Maciek: Exactly. To show how detailed even a simple step like setting up the environment can be, we can describe what we do when setting up a store on Shopify.

Tomek: Sure. Step by step. We start by checking that the newly created store has a password set, so that nobody can get into it during development. Then we enter the owner's details and company details, set up the addresses of the company that owns the store, and the billing details for Shopify. Then we move on to configuring payment gateways. At the same time we enable testing them with sandbox accounts, so we can test those processes in the testing phase. Tax settings, settings for…

Maciek: …payments, shipping zones…

Tomek: …shipping zones, that is, carriers. Next, right away, we add the list of people who'll have access to the store. Precisely for the reason we mentioned: so they can get to know the environment and learn it from the very start. What else? The email addresses the store will communicate from. Here we can also go into the DNS records the domain needs for Shopify.

Maciek: Yes, exactly. You need to add an SPF record to the domain, a TXT record that says Shopify may send emails from our address on our behalf, so they don't end up in spam.

Tomek: Sure.

Maciek: A detail, but an important one.

Tomek: An important detail. We're giving the full list precisely to show how many small pieces of this puzzle are needed. Finally, privacy policies and terms and conditions. Those can also go in at the very beginning.

Maciek: That's right.

Design: a ready-made theme or a design from scratch?

Tomek: Let's move on. There are two stages we can run, and usually do run, in parallel. On one hand, work on the visual layer of the new store, and in a moment we'll say what that step looks like with Shopify. On the other, as we said, we deal with the data import straight away. We'll also cover which data and in what order, because it matters.

Maciek: The first topic is fairly simple, the second more involved. So, quickly, on design. There are two approaches. We can work on a ready-made theme and customise it, but we don't recommend that approach. We'd rather recommend designing the interface from scratch.

Tomek: And why? Can you expand on that?

Maciek: Our experience shows that sites designed for your users achieve better conversion rates. So the saving you make by working on a ready-made theme is illusory. Second, they're often simply faster.

Tomek: So custom solutions perform better. I think we can leave it there.

Which data to migrate, and in what order?

Tomek: Let's move on to data migration. First: what data do we mean when we talk about migration? Second: why is keeping the right order important?

Maciek: First of all, you need to think about which data you want to, can and should migrate. The first thing is importing products, then customers, but also orders. Those are the three basic data groups. There are other things too, such as content we have to move: blog posts, text pages, maybe discount codes, and SEO-related things, for example.

Tomek: Sure.

Maciek: And the order is as follows: products first, then customers, and orders last, so that in the order history we can show the links between customers and products. That gives us the customer's order history, we can see what they bought, and it allows better analytics.

Tomek: I'd add why we want products migrated first. Because then, in both the design phase and above all the development phase, we work on real data straight away. We don't have to mock up or simulate a sample product. Remember that different products have different attributes and characteristics: toys look different on product pages from power tools, and fashion different again. Importing products first makes development easier and, as you said, later lets us link customers to products and gives us information about order history.

Why can a product import take weeks?

Maciek: It's worth mentioning that "product import" sounds very innocent, but it's often quite a complex process that, depending on the structure and amount of data, can take weeks.

Tomek: Why? What's the reason?

Maciek: There are several reasons. First, every platform has its own data structure. Say your products are laid out in a table, with a product's variants in columns, for example. You can have different fields describing a product, arranged differently from the target platform.

Tomek: So adapting the data structure is often quite a big challenge.

Maciek: Exactly. Unless you have a PIM, a product information management system. Then it's relatively simple and painless. If you don't have a PIM, you often have a problem. Shopify does have tools for migrating from the most popular platforms, Magento or WooCommerce, but not everyone is on those systems. Very often we migrate from others. You can try editing CSV files by hand. There are tools that help with the mapping, such as Matrixify, which we particularly recommend. You can also migrate data via the API. But both editing CSV files and working with the API often require writing a script that turns one data structure into the other. Then we run the import, and at that stage shortcomings often show up too: something needs fixing, something got lost, we forgot about something. And that takes time.

Customers, order history, content and discounts

Tomek: The factor that definitely affects complexity is scale. The more products, the bigger the database and the more advanced the solution it needs. With a small database and few products it's often enough to enter them into the new system by hand. The bigger the scale, the more you need an automated solution. It's very similar with customers. Here too we have CSV files we can import into Shopify, but they have their own structure, often different from the structure of the source file. So we have to convert one structure into the other to be able to import them.

Tomek: As for order history, let's say what's possible in Shopify and on what terms. The general rule is that only the Shopify Plus plan lets you import order history by default, natively. You can use the Transporter app for that, which lets you pull in the order history. It isn't compatible with every system you import from either, so the data often needs extra preparation. That's for Shopify Plus. On the other plans there's no classic built-in import; the button is simply inactive. Apps come to the rescue, such as the Matrixify we mentioned, which lets you import this data. But again you have to reckon with preparing the data, working it up in the app and using a paid app, which Matrixify is.

Tomek: Those are the key data. But remember that you often also need to migrate typical content pages, such as blog posts from your current site. And if we had discount codes on the site and a whole policy around them, we have to think about how to reproduce that in Shopify. Be aware that with discounts and discount codes, solutions that stray a bit from standard selling, every system has its own logic. We may not hit a wall exactly, but we may run into difficulties reproducing them one-to-one. So the import often comes down to physically recreating them in Shopify, or modifying them slightly so that the business model is preserved as closely as possible. On Shopify Plus, which we talked about last time, Shopify Scripts help here, extending the discount functionality further.

What is a delta migration?

Tomek: The last thing on data migration, but by no means the least important, is something called a delta migration. Tell us, Maciek, what that means.

Maciek: If we import data at the start or during the process, we have to remember there's a good chance some of it will go out of date between the import and the launch. So just before launch you need to run a so-called delta migration. Maybe your products won't change because you have a fixed range, but there may well be new customers and new orders, and stock levels will certainly have changed.

Tomek: Sure.

Maciek: So you simply need to update the data so that what's in the system is current. Not "as current as possible", just current.

Tomek: Current. That varies, because if someone has a very large number of transactions, the data changes every hour and it's hard to capture that perfect live moment. But the closer the better.

Maciek: The best time for a delta migration is when we take the production store down and switch it to maintenance mode for the duration of the migration.

Development and integrations

Tomek: Let's move on. The data is migrated and the visual design is done too. We reach the hard development phase, which we split into front end and back end, and which can run in parallel.

Maciek: The back end can start earlier, because very often it concerns integrations with the various systems we have to connect our tools to. The front end has to wait for at least part of the design before we can start.

Tomek: Could we give some concrete examples of those integrations? What gets integrated most often?

Maciek: For example, you want to integrate the store with a video platform, or turn on Algolia, a search engine, or integrate Klaviyo or Gorgias, other tools for different areas of e-commerce: marketing, customer service, loyalty. Or an ERP, or in parallel there's an integration with a custom PIM or a warehouse system.

Tomek: So all the systems we mentioned earlier that make up the sales ecosystem. This is when they get integrated.

Maciek: And the benefit of importing the data earlier is that we can check how…

Tomek: …how the data exchange works. So far we've talked very generally about which systems get integrated, but our process of course identifies those areas and systems. The next thing we handle is setting up marketing tools, that is, integrating and configuring them. On one hand that means social sales channels: integration with Google, Facebook, Instagram, the channels where the business sells or wants to sell. Because, as we said at the start, the workshops may show that we only now want to open those channels, and in Shopify they'll be available. Then the classic CRM systems that support marketing. I'd name HubSpot and probably Salesforce.

Maciek: edrone.

Tomek: edrone, our Polish one, absolutely. So the systems we use for customer communication, ads and newsletters.

Maciek: We should add that integrating CRMs or tools that work on the front end often has to wait until the front-end coding is ready. If only because marketing automations very often happen in specific places on the site.

Tomek: Absolutely. So the marketing tools are taken care of, we've integrated the ERP if there is one in our setup, and it looks like we now have a fairly complete solution. Is this the moment we decide to launch? Do we go live with the store? Or is there something to do first?

Pre-launch testing

Maciek: I don't recommend it. Before that, we go into the critical phase of pre-launch testing, which helps us catch any remaining shortcomings.

Tomek: It would be good to say what our pre-launch testing checklist looks like: what we examine, what we test, why we do it and why it matters. Do you want to start?

Maciek: I can start. I'd begin by testing the critical paths in e-commerce, that is, whether the purchase process works. You have to test the user journey from the home page through the listing, the product page and the cart to the checkout. That also means browser testing, whether all features work. Traffic comes from different sources and different browsers, so all of it has to be tested. Next we test transactions: whether all payment gateways and all shipping methods work. That covers both completed transactions and ones that failed. You have to remember those too: what happens when something breaks along the way, and how to handle it. That area often gets forgotten.

Tomek: I'd add one thing. You covered everything that happens on the front end, what the customer sees and will experience. In parallel we need to test what happens to the orders that come into the store: how they're passed on to the systems that handle fulfilment, whether they land in the CRM and the ERP. We have to check that the business also works as expected on the back end.

Maciek: So order fulfilment, order cancellation, returns.

Tomek: Yes, exactly. I'd also add checking how notifications are sent to the customer.

Maciek: Partial orders.

Tomek: Partial orders, newsletter sign-ups. So both the strictly business side and the marketing, business-adjacent side.

SEO in a migration: from workshops to testing

Tomek: This is also the place to mention SEO, which we brought up at the start as an area that's sometimes neglected or not looked after well enough. We always recommend that the SEO agency, or the people responsible for SEO on the client side, take part in our workshops, especially the technology ones where we map processes. For us, search positioning and the store's position in Google are a key, business element.

Maciek: We had a case of a client who was super enthusiastic about the solution, and we held the kick-off workshops that were meant to start the project. It fell apart because the SEO agency had very specific requirements for the link structure, and moving to Shopify meant that structure had to change at the time. That could have been avoided with a headless approach, but there were other requirements there and that's what it broke down on.

Tomek: I agree, I remember it well. It was about the links generated by filtering. A fairly unusual requirement, but it shows how extremely important this is for some businesses.

Maciek: If your traffic comes mainly from SEO. Sometimes it's not an issue: we have loads of businesses that run on performance marketing, sell through paid social campaigns and don't focus on SEO at all.

Tomek: Even so, in the testing phase we also want to cover SEO: check descriptions, titles, alt texts, whether there are broken links, and the 301 redirects that are critical for the store. There's quite a lot of it, and this is also when we often ask the agency handling it for support, so they can run tests on their side and check it meets their expectations. It's the last moment when we can modify at least some things and adapt them to those requirements. As you can see, there's quite a lot of testing, but it still doesn't mean we're one hundred per cent sure the store is perfect. The final check, as we'll discuss in a moment, is putting it live, but we're much better prepared for it.

When to launch the new store, and when not to

Tomek: We've reached the last stage: planning the store launch. Let's think, Maciek, about when to do it, or, the other way round, when not to.

Maciek: It's always a super stressful experience for founders and e-commerce managers. It's the climax, and emotions often run high. It's best done when the store has the least traffic, so it's worth waiting.

Tomek: So the first thing is analysing the store's statistics and working out on which days and at which hours traffic is lowest.

Maciek: Exactly. Most often it's late evening. We've often even run migrations like this after midnight.

Tomek: And what about the day: the weekend? As a rule that's when traffic is lowest.

Maciek: Doing it at the weekend is a great idea, except it's worse if you don't have support then.

Tomek: Sure. So yes, let's do it when traffic is lowest, but…

Maciek: …let's not do it on a Friday.

Tomek: Let's not do it on a Friday or at the weekend. That way we can be sure that, if errors come up, we can count on support from a developer or the agency that helped us first thing the next morning.

Maciek: We offer our clients what's called hypercare: a period of a few weeks after launch when we're on standby in case anything happens. It has a very reassuring effect.

Tomek: Yes. When clients ask what happens afterwards and what support they can count on, I often stress one thing that matters with Shopify itself. If we're talking about unexpected critical errors that we might expect after launch, Shopify does a great deal to prevent them. In e-commerce, the truly critical errors are the ones that interrupt the purchase process and the store's basic operation. And Shopify takes care of that through its checkout. So the level of stress and risk is certainly much lower.

Maciek: I'll agree with that. Although when I think back to various situations, they seem funny in hindsight, but at the moment of switchover they often aren't.

Switching the domain over and the first hours after launch

Tomek: And the switchover itself? We need to be aware that the domain stays the same, but the store that handles the traffic and serves the content changes. How long can that take?

Maciek: In theory, domain propagation, informing all servers that this address now points to a new IP address, can take up to 24 hours. In practice it's an hour, two at most, before the address has propagated.

Tomek: So relatively short.

Maciek: There's often a period when you type in the address and see the old store while someone else already sees the new one, and that causes needless nerves. But it's a natural…

Tomek: …a natural process.

Maciek: Exactly.

Tomek: So once the store is live, can we sit back and enjoy the new solution? Or…

Maciek: Usually people go to bed then, get up very early in the morning and check that everything is still running. Of course you have to check the critical things. First, whether the business metrics are working: are orders still coming in, is traffic arriving from the channels we wanted to keep. We can hook up analytics tools such as Hotjar, which shows user behaviour and helps catch errors we didn't catch during testing. We can also look at analytics and check whether error pages or links to non-existent pages have appeared that we missed. And one more critical thing: we have to check the data exchange between systems. We did all of that earlier, so it works 99.99% of the time.

Tomek: I'd call it vigilance after launch. We've gone live with a new system, so let's monitor the indicators and metrics for deviations or results that differ in any way from what we've seen so far. And let's monitor the back-end, business layer: is the data intact.

Why keep the old store after a migration?

Maciek: Exactly. And remember that, just in case, we still have the old store. We can briefly point the domain's traffic back to it, depending on how serious the situation in the new one is. But that very rarely happens in practice. I don't remember us ever having to roll back.

Tomek: We haven't had that. But what you stressed at the start, keeping the old environment for a while after the new one goes live, certainly gives a sense of security here, just in case.

Maciek: If only to look up archived orders, discount codes or charges in the old system. All sorts of things are scattered around there.

Tomek: All the more so because customers who see the new store are learning it too, and sometimes contact the owner or the helpdesk asking where to find features that were there before.

Maciek: "How do I do this, because here we used to do it like that."

Tomek: Exactly. It's good to be able to look at how it worked in the previous solution so you can answer quickly.

Summary: a proven process instead of stress

Tomek: Maciek, I think we've managed to bring this process safely to shore. It took a while. As you've seen, the whole process is fairly complex, covers many areas, and it's important to stick to the structure. So maybe a summary and a piece of advice for people who are thinking about migrating, are a bit afraid of it or are wondering how to approach it.

Maciek: The conclusion could be that following proven processes and procedures will minimise the risk and make sure the process is organised and well thought through, and as you go through it you'll feel it's simply safe. Because the biggest fear with migration is probably the risk itself, and with it come a lot of doubts, worries, stress and nerves. And because of that, often mistakes as well.

Tomek: Great summary, Maciek. Thank you very much for another conversation and another episode together. And thank you all very much too. I hope we've managed to pass on some useful advice on how to approach a store migration, how to avoid mistakes and how to minimise the risk involved. Many thanks for today, and see you in the next episodes.