Episode #1: reducing risk through a platform migration

Episode #1: reducing risk through a platform migration

Ensuring a successful website launch involves these two critical steps.

Scroll Down for more info

If you are like most, you have experienced a move: maybe to a different flat in the same city, or maybe to another country. My story is unique in that I’ve lived in pretty much the same city all my life. It’s nothing special, but I am grateful for it. Before I moved out of my family’s house, I had the opportunity to help my family first build a house and then worked through the process of moving into it. It can be stressful, and you want to make sure that everything works.

This analogy of moving into a house is quite a parallel to replatforming your ecommerce site:

  • It’s pretty well inevitable (Magento 1 end of life means you need to find something else, whether that is Magento 2, Big Commerce, Shopify)
  • It takes a lot of time. Unfortunately, there is no replatform service that is the flip of a switch.
  • It takes money. Your code and website was quite happy as it was. Now you need to figure something else out.
  • It is risky. How do you ensure that you aren’t making a really bad choice? Or that the people you are trusting to do this migration actually know what they are talking about?

My focus in this information is primarily on the last point: it is risky. We have all heard the horror stories of merchants replatforming (they’re promised higher sales), but their revenue drops after the launch. While most everything in life has a risk factor associated with it, the fact that your website is feeding your children increases the risk in such a change.

My goal is to equip you, the merchant, with basic tools so you can reduce your internal risk metrics and feel comfortable in a quality re-platforming project.

Part 1: will search engines find pages on your new site?

When you replatform, the new platform will likely have at least some changes in it’s hierarchy, and thus the linking structure. For example, your previous product might be found at https://swiftotter.com/products.aspx?id=12345, but you are making your new website more search-engine friendly and now the same product is found at https://swiftotter.com/my-awesome-product.


Not good!

You just launched your new website, but visitors from Google see this?

The problem is if you do nothing about this change in URL structure, visitors will search for “My Awesome Product”. Google will show them the link to https://swiftotter.com/products.aspx?id=12345, they will get a “Page not found” error, they will immediately click back, and you just lost a potential customer. Remember, Google is not the only issue. Hopefully, you have many links to your website from other websites, recommending your products content.

Example:

Let’s say our old website is https://myexamplestore.com. You can find our best-selling gizmo here: https://myexamplestore.com/view-product.php?sku=amazing-gizmo. You are migrating to a new BigCommerce and have imported all of your products. The design is ready to go, and you pull the trigger. Customers are now browsing the new website. When they go to your store, they can easily find Amazing Gizmo using the search or navigation system.

However, when you search in Google for “Amazing Gizmo”, you are presented with this URL:

https://myexamplestore.com/view-product.php?sku=amazing-gizmo

Unless you have taken action to redirect this URL, this is where customers will land. On this new platform, they will see a "This page is not found."

How can I ensure that Google will find the new URLs?

Hopefully, you have already established redirects. These steps will give you peace of mind (or freak you out) that there are no stones left unturned with regards to these files.

We recommend and use Screaming Frog. It is 150 British Pounds per year. If the price scares you, think of how much this may save you. If 20% of your links will error out, you could lose way more than 20% of your revenue. And, no, the above is not an affiliate link.

Step #1: Scan Existing Site for all URLs:

  • Open Screaming Frog
  • Mode->Spider
  • Configuration->Spider. Deselect images, CSS, javascript, and SWF
  • When scan is complete, view Internal Tab. Filter “HTML”. Select all addresses and status codes and copy to a spreadsheet.

Step #2: Scan same URL’s on new site:

  • The existing list of URLs will have the old website’s domain in each URL (https://olddomain.com/page-1.html). Do a search and replace to change out the domain name for the place where your development website is located (for example, https://dev.newsite.com/page-1.html).
  • Use a spreadsheet editor, like Google Sheets, and use tabs to keep track of the project’s progress.
    • Tab 1: list of URL’s from existing site
    • Tab 2: list of URL’s converted to new/DEV site
    • Tab 3: result of first scan on DEV/site
    • Tab 4: result of second scan on DEV/site
  • When the list of URL’s is configured for the new site, Screaming Frog:
    • Configuration->Spider. Deselect images, CSS, javascript, and SWF
    • Mode->List (then paste in URL’s)
    • Keep in mind that the development site may have traffic restrictions (for example, MageMojo’s Stratus platform). To throttle Screaming Frog: Configuration->Speed. The Max URLs option is how many URLs per second will be scanned.
  • When the scan of new development site using existing URLs is complete:
    • View the “Response Codes” tab in Screaming Frog.
    • Review all the various response codes, however, filter to 404’s (not found).
    • Copy the Address and Status code column out and paste into spreadsheet, new tab, clearly labeled.
    • Troubleshoot the 404’s looking for patterns. Additional columns on the spreadsheet can be used to list the existing site URL, as well as what the existing site does (redirects, displays a page, 404, etc.). Notes can also be added.
  • Scans can continue to be run using the 404 list, which should get smaller as systemic issues are addressed on the new development website.
  • When all issues are resolved another full scan of all HTML URLs can be run on the new development site.
  • Following site migration, all HTML URLs should again be run on the new site.

Share this spreadsheet with your developers. Your developers might put 1:1 redirects, or use other techniques to match multiple old URLs. Depending on the platform, they may even build functionality into the system. For example, they can locate a product’s SKU in the URL, check the database to make sure that product exists, and then redirect to the right page.

A note about redirect codes:

In the above spreadsheet you just developed, it is important to watch the response codes. There are two redirect codes, and one of them can be quite dangerous for your hard-earned search-engine optimization.

302 redirects mean temporary. After a customer logs into your website, they will be redirected to a welcome page. That redirect is a 302, as it’s temporary and transient. Redirecting old URLs to new URLs should NEVER be a 302, as they are not temporary.

301 redirects are permanent. This is what you use for replatforming.


Part 2: what UX do you need to know?

In today's world of beautiful design, you will find UX this and UX that. First, what is UX? It is an acronym for User Experience: what does the user experience when they are on your website (or app, etc.)? Do they like it? Do they find what they need?

In a future episode, we will delve into Google Analytics metrics to compare before and after replatforming. While those are helpful, they still require you to interpret results and make judgement calls.

What you can do today (before you go live):

Take your “I’ve done this many times” glasses off, as best you can, and browse the website as if you have never been to it before. Do a Google search, click into your old/existing website. What hits your eyes first? Where do your eyes go next? Add a product to your cart. Check out your cart (I’m amazed at how few store managers actually use their own checkout process).

Now, roughly mimic that process on your new website. I'm guessing you will find at least 25% of the biggest problems on the website. The next step is to enlist the help of your friends. Offer to buy them a coffee and then user test the new website with them. Of course, bring your laptop so you have a medium on which you can ask them to take these actions.

Ask your friend to speak their thoughts. Check your ego at the door, and keep your mouth shut during this process. I know from first-hand experience, I want to explain my thinking. While you may not be able to fully accommodate their wishes, you will at least have a good idea as to what other users are struggling with.

I have learned when doing user testing to watch for what they stumble on versus what their opinion or preference. Take action on the pain points (especially when you see a trend of 2-3 or more people run into the same problem). Listen to the opinions and put those on a list for later.

Example:

We recently did an audit for a company that sold commodities. They migrated from Magento 1 to Magento 2 and their sales dropped by 20%. While they had a few technical SEO issues, those were minor.

Old site shopping cart link:


Before, this was functional, but less so beautiful.

Is this beautiful? Not really. But, more importantly, it gets the job done. When we add something to our cart and now wish to checkout, we commence a search on the page for a shopping cart icon.


Now, these links are much smaller and compact and people have trouble finding them.

While the new header is a little more compact, user experience took a nosedive:

  • Customers were used to seeing “shopping bag”, and not a cart icon.
  • The cart is small in comparison to the previous real estate.
  • The account and cart links are switched. This has the effect of burying the cart between the total amount in the cart and the user account symbol.

The above leads to it being hard to find a cart icon. That shouldn’t result in a 20% decrease in sales as most people will still find the cart. Maybe, though, we could estimate it having a 1-2% impact?

If you add up many 1-2% impacts, you will quickly get to 20%.

Summary: comb over your website. Bring in your friends (one at a time) and observe them using the website.

Please feel free to get in touch with us to share your story. We promise to listen and sympathize.

SwiftOtter, Inc.
It relates to Magento 2.
Joseph Maxwell - president / senior developer at Swift Otter

President / senior developer at SwiftOtter - @josephmaxs