In my last post, I talked about why I’m investing heavily in a new website and how to prepare for a complete redesign of your store. In this post, I want to take you inside our website migration process for going from theoretical concept to a shiny, non-botched live new store.
This is my 3rd large shopping cart migration, so I’ve made all the mistakes in the book. From managing a team, to technical issues to dealing with project fatigue, I’ll be covering it all.
Rolling out a new design for your online store is an involved process. Migrating to a new cart is complex, too. But when you combine an entire site redesign AND a migration, you end up with a monster of a project. There’s so much to think about and consider that getting started can be downright terrifying.
But don’t psych yourself out too much. If you’ve followed the steps in my guide to preparing for your new website design, you’ll have a crystal clear idea of what you want to do. Now, you just have to create a plan and execute on it.
There’s something amazingly cathartic about getting everything you need to do written down in one place. Apart from helping you come to terms with the project size, it makes it much easier to delegate and nail down timing / scheduling / etc.
Before doing an ounce of work, I wrote down itemized, granular tasks for everything we had to do before the launch. Your list will inevitably grow, but building this foundation at the outset helps tremendously.
We use Asana for all of our team management / collaboration, and it worked wonderfully. But it really doesn’t matter what you use. Pick something (Asana, Trello, Basecamp) and just make sure everything regarding your project lives there.
So you want to launch in 2 months? Great! But is that a realistic time table or will you be working your team to death to hit your arbitrarily chosen date?
One of the great things about outlining your workload from the outset is it helps you schedule realistically. Thinking through and assigning approximate times for your tasks, you can quickly get a sense of when you can realistically launch.
We had a team of 5 in-house team members and 3 contractors working on the redesign, so delegating well was crucial. If you’re working mostly on your own, you’ll still likely want to leverage some contract work to make your life a bit easier and speed up the project.
Breaking tasks down into the level of complexity and time required can really help with this step. There’s a lot of repetitive, time consuming tasks that come up with a website migration which you almost certainly shouldn’t doing. Instead, leverage your existing VA or hire a temporary one to help you out.
When it comes to more complex tasks, ask yourself:
If you answer yes to either of these, you’ll probably want to tackle the project. Otherwise, delegate it to a team member or a contractor you can hire. You can find tips for finding top-notch outsourcers here.
You’ll be assigning a lot of one-time projects to your team and outsourcers. You could try to type up in-depth instructions or have time consuming phone calls. Or you could use screencasts.
I’ve created and shared dozens and dozens of screencasts over the course of our redesign project, and they’d saved me countless hours of work and back-and-forth. Video screencasts may not be ideal for SOPs that are used frequently and need to be scannable, but they sure work well for one-time tasks.
I’d highly recommend the Chrome App SnagIt for creating screencasts. It lets you share your screencast almost immediately after you’ve recorded it, so you can move on to other tasks vs. waiting for your video to render.
The dynamics for working with your developers / designers will likely be different than coordinating your in-house team. Here are a few things to keep in mind:
It will likely take weeks – if not months – to get the first version of your new website live and ready for review. But that doesn’t mean you can’t get started with things from your side.
Even if your new product pages aren’t ready, you can have your team start migrating products to your new cart. As long as you and your designer are in agreement with how the data needs to be formatted to display properly, you can do much of the heavy lifting while the site is being built.
Pay special attention to dependencies that need to be taken care of first, and prioritize getting those finished ASAP.
Nothing is worse than death-by-a-thousand-changes for a developer. You’ll unquestionably have changes after seeing v1.0 of the design, but try to give feedback to your designer in batches so it’s easier for them to process. For our project, we had three major series of design refinements as opposed to driving Carson (our developer) mad with changes every day.
Nothing is worse than death-by-a-thousand-changes for a developer.”
Make sure you have a document you can record these changes in as you come across them. You may think you’ll remember them when it comes time to sent them to your dev team, but you’ll almost certainly forget a good portion.
There’s a good chance your dev team will come to you with something they said they could do in the spec, but is now difficult and/or impossible. This is especially true if you’re on a hosted cart as you can’t control the underlying code (learn more about eCommerce shopping carts here).
In this situation, you have two choices: 1) get upset about it and demand it gets fixed (our natural inclination) or 2) extend empathy and understand this comes with the territory. The second one will serve you much better in the long run.
I’ll be covering the actual design and UX changes to the new Right Channel Radios site in my final post, alongside the results of the redesign. In this section, I want to discuss the “must-do” technical items you need to take care of to ensure the migration process goes smoothly.
One of – if not the biggest – thing you’ll need to address with any shopping cart migration is your URL structure. In a perfect world, you’d be able to replicate the same URLs for your pages as existed on your old site.
That’s often impossible. For our migration, Shopify uses a fixed URL format so it was impossible to preserve the exact URL structure. So it’s crucial that we redirected the old URLs to the new ones.
One of – if not the biggest – thing you’ll need to address with any cart migration is your URL structure.”
Redirecting your URLs does two things:
The specifics of how to implement these redirects will vary based on what platform you’re on. On Shopify, we’re using the app Traffic Control to manage the process. If you’re self hosting on a linux webserver, you’ll likely be editing your root .htaccess file (see this Rackspace article for details on how to do that).
With past website migrations, we’ve used the transition as an opportunity to improve our meta data. Meta data – specifically the meta title and meta description – are what often appear when your site is listed in Google and other search engines.
This time however, we’re leaving most of our meta data the same. This is 100% speculation on my part, but I wanted to reduce the number of SEO variables changed with the transition so that we could isolate issues if we run into issues with organic traffic taking a nosedive.
If traffic is fairly stable after the transition, we’ll go ahead and start to update our meta titles and descriptions. But for now, we’ll be leaving them as-is.
The same goes for URLs as well. While we weren’t able to maintain the exact URL structures, we tried to keep them as close as possible. For example, while Shopify requires us to have “/product/” in the URL of all products, we’re keeping the same root URL identifier.
For example, the new and old links to our Cobra 29 LTD radio are below:
Again, I don’t have any hard data to back this strategy up but it’s something we’re doing out of caution to limit the chances our organic traffic takes a hit.
There’s two primary types of data you’ll need to think about moving from your old cart to the new: product data and customer/order data. I’d strongly recommend manually migrating the former and using an automated service to move the later.
The idea of using a service or script to automatically move products from cart A to cart B sounds nice. But in reality, it often ends up a disaster. Different carts and themes have different fields, markup practices and ways they format product information. And then there’s product options and bundled packages, which further complicates any automated migrations.
My recommendation and what we’ve always done is to manually migrate your products. This way, you know the data is being moved properly and it’s a great chance to improve your listings at the same time.
When it comes to customer data, however, I’d highly recommend using an automated shopping cart migration service like Cart-2-Cart. Customer address and order history data is fairly standard, and we’ve had great success moving it during migration with their service.
It’s unlikely historical ordered products will match up perfectly with the new products in your store, but you will have a full order history in your new cart. The alternative is having to keep your old cart online to check historical customer records. Not fun.
DNS issues, which stands for Domain Name System, are probably some of the most confusing you’ll deal with if you’re tackling your first website migration. I’ve done three migrations, and I’m only now getting comfortable with what the DNS system is and how it works.
A DNS intro is far beyond the scope of this post, but here’s a high-level explanation.
The DNS system tells computers where a particular website lives on the internet. When a computer tries to load eCommerceFuel.com, for example, it first queries a DNS server to get the server address (called an IP address) associated with the eCommerceFuel.com domain name. Once it has the IP address, it can then find the exact computer hosting the website.
When you migrate shopping carts, you’ll likely be moving to a new server. Your domain name won’t change, but the server address – again, called an IP address – will change. So you need to update that IP address with your DNS sever.
Confused yet? I’d strongly recommend this oddly entertaining DNS video primer to get up to speed (see below). If you’re not clear on how DNS works, watch it. It’s really important to understand as messing up DNS issues can cause a lot of stress come launch day.
Here’s a few DNS related tips to make things easier as you migrate.
You’re almost certainly developing your new cart on a separate site, say dev.rightchannelradios.com. Once you’re ready to go live, you’ll update the DNS settings so that your dev site will now load as your primary site, ie – ww.rightchannelradios.com.
Flipping that DNS switch can be scary, and most people simply hope the transition goes smoothly. But if all your settings aren’t configured correctly, you could launch only to find your site not working properly. That’s why I’d recommend a dry run of updating your DNS information.
Here’s what you do: you in effect “trick” just your computer to load your new not-yet-live website using your real (not development) domain. This allows you to see what everyone in the world will see when you update the world wide DNS settings, but without out all the high stakes consequences if something isn’t configured correctly.
For instructions on how to do this, check out this article from WPEngine. It can be a little involved to do, but it’s well worth it for the peace of mind it delivers knowing that your migration will go smoothly.
Your DNS records have a TTL variable, which stands for Time To Live. This tells computers how long to “remember” where your site is located online. So if your TTL is set to 24 hours, computers will only check back once every 24 hours to see if your website has moved.
This can be a problem when you launch a new site, because you want people to be able to access it as soon as possible. But if your TTL setting is too high, people will be sent to your old site for hours – even days – after you’ve pushed your new one live.
A few days before you’re ready to launch, reduce your TTL setting for your DNS A Record record to 5 minutes or so. This way, when you update your DNS settings, the new address will propagate quickly and people will be able to access the new site without delay.
A few days after the launch when you’ve confirmed everything is working well, go ahead and set your TTL back to the previous higher level again, as this will help your site load more quickly for new visitors.
Forgetting to customize cart emails is a classic mistake for first-time migrators. Nothing is worse than having a beautiful new site sending out obviously generic stock cart emails.
Here’s a list of the emails you should be thinking about setting up and configuring on your new platform:
“If it can break, it WILL break” is the philosophy you should adopt when migrating to a new cart. Unless you’ve seen it work properly with your own eyes, you shouldn’t assume it is.
“If it can break, it WILL break” is the philosophy you should adopt when migrating to a new cart.
Before going live, you’ll want to spend a lot of time stress testing your new site and order flow. Here are a few things to do:
As you’re starting to see, there are a mountain of details to remember when undertaking a website migration. I’ve complied a comprehensive shopping cart migration checklist which is available to private forum members here.
Not currently a forum member? You can learn about the eCommerceFuel Private Forum and apply for membership here.
Migrating shopping carts can be a massive undertaking. The migrations I’ve done easily count as some of – if not the – largest projects I’ve ever embarked upon in my entire life. Often, you’ll be looking at the better part of a year from beginning to end. Our redesign of Right Channel Radios took nearly 6 months – and that’s with a good sized team cranking away.
Project fatigue is going to hit you. What was initially “This website is going to be amazing!” will inevitably slip toward “Let’s just get this thing launched before I go mad” the closer you get to the deadline.
Putting off the launch for a month to perfect the final 3% of your to-do list is a mistake.”
Don’t get discouraged, this is completely normal. As fatigue sets in as you get close to the finish, try your best to maintain your standards. If you’re anything like me, you may not revisit aspects of your new site for YEARS. So getting them right now could mean the difference of thousands of dollars of profit or loss.
Ultimately, you have to set a launch date and I can say with confidence you won’t have everything on your ideal to-do list finalized when it comes. Do your best to launch when you feel the site is mostly ready. Putting off the launch for a month to perfect the final 3% of your list will probably be a mistake.
You can always tweak things after launch if they’re important, and the longer you delay a launch the longer until your newer and more (hopefully) profitable new cart can start making you more money.
Shopping cart migrations are an insane amount of work. But few things compare to the rush of flipping that switch, pushing your new site live and seeing a 20, 30, 50% – or more – increase in sales.
That’s what I’m hoping will happen with our new site design, scheduled to go live in less than two weeks. Check back in soon for a full report on the new site, the changes we made and – most importantly – how they impacted sales.
If you’re interested in diving deeper into website migrations, I’d encourage you to apply for membership in the eCommerceFuel Private Forum, a vetted community for established store owners & eCommerce professionals.
You’ll have access to in-depth discussions like this one on mitigating the risks of moving carts. There’s also this thread of members sharing the impact their migration had on their store’s traffic. Like most forum threads, these are detailed discussion written by experienced store owners sharing real-world data.
Get access to thousands of similar discussions and 500+ experienced eCommerce entrepreneurs and professionals by applying for membership today.