The move to Magento was one of the worst periods of my life, but it led to enormous success. Here’s what you need to know about Magento migration.
For years I ran my own e-commerce retailer on Magento. The platform allowed our company to experience incredible growth, scalability, and ultimately a successful exit.
The downside? The move to Magento was one of the worst periods of my life. In migrating over our growing, profitable, SEO-optimized business, we nearly lost the whole enchilada.
When I say “lost,” I mean LOST—as in “going out of business.” As in millions of dollars in revenue dropping to zero. It was a year of total pwnage.
If that last sentence scares the bejesus out of you, if you happen to be considering a shopping cart re-platforming or migration, read on.
The Early Days: Fun with a DIY Shopping Cart
We built our retailer from the ground up in 2003, coding the site and shopping cart ourselves.
This gave us a few big advantages. It kept costs down and let us be flexible—we were able to quickly deploy features in response to customer requests. For a bootstrapped retail brand focused on service, it was perfect.
By 2008 however, we were becoming increasingly frustrated with our homemade platform. Our retailer was generating several million dollars in revenue and drop-shipping products from hundreds of vendors.
We wanted to spend less time in the coding weeds, and at the same time roll out cool front-end features like multi-store functionality (pioneered by competitors CSN/Wayfair and Hayneedle).
It would take us months to build stuff like that ourselves.
Magento offered a promising solution. Because it’s an open-source, PHP-based system we knew there was an army of third-party developers out there who could help us improve the site.
And the defining feature of Magento (in the early days) was its multi-store capability.
So after testing the beta version and drooling at all the built-in features, we decided to take the plunge.
Our Magento Migration: AKA the Valley of Death
Confident hackers, we decided we could re-platform our site to Magento ourselves.
We spent a few months preparing—we wrote queries that would move all our product, customer, and order data from our original MySQL database over to Magento’s database in a matter of minutes.
We developed some command-line scripts to pull over all our product images to a new host. And we developed the new, slick Magento front-end theme, complete with all the free extensions we could get our hands on.
On the evening of November 14th, 2009, we migrated the site. I put up a maintenance page, updated the DNS, and began executing queries to move all our data.
I couldn’t wait until the next morning when our customers would experience a new, better, faster, more functional DesignPublic.com.
“Just how much would conversion rates increase?” I thought. 20%? 30%? Where would I put all that additional cash?
The next morning came, and the site was still down. I don’t know how long it remained down — it’s hard for me to remember now because I blocked out that time as a PTSD coping mechanism.
I do know that over the next few weeks, I pulled about 10 all-nighters working on our server. My social life and relationships ground to a halt. The site remained unreliable for weeks, if not months.
With the site frequently down, revenue went to zero. Even worse, our top-ranking pages all plummeted because of the site’s skyrocketing bounce rate.
Every day I would check our Google rankings to find we’d dropped another few positions for our key terms and brands.
Months later when we ultimately did get the site humming, our rankings — and revenue — lagged. It was almost a year until our revenue run-rate recovered.
What Went Wrong? Four Things…
So what went wrong, and more importantly, how can you avoid the same nightmare?
1. We raced head-first into new, beta software
My co-founder and I are early adopters. If there’s a new iPhone, we want it. A new piece of software? We start drooling.
When Magento launched, we ignored the “beta” label and only saw that it would solve all our development nightmares while adding a slew of shiny new features to help us grow our business.
In retrospect, we should have waited for a revision or two. Early versions of Magento were extremely buggy.
Things didn’t work well out of the box: front-end crashes would happen daily, and random system caches would gradually fill up and torpedo the server.
All this would have made it complicated to run a simple five-product store.
For us, with a complex catalog of more than 20,000 products with heaps of traffic and specific drop-shipping demands on the back-end, the bugginess was crippling.
I remember looking at Magento’s public bug-tracking system and thinking: “Wow, we have contributed over half of these things.”
It was pretty optimistic of us to expect the migration to come off without a hitch. Today Varien has stripped this “beta” label off the product, and the software has undergone no fewer than ten major revisions.
As a result, it is battle-tested and migrations should avoid many of our early troubles.
2. We vastly underestimated the server requirements
Upon migration, DesignPublic.com immediately became unresponsive due to some combination of the complexity of our catalog, the volume traffic to our site, and the limitations of our existing hosting package.
We had to change hosting providers three times over the next two months before obtaining a functional site — with each move we’d increase the server size or processing power.
When the site slowed to a crawl, our bounce rates would skyrocket. This sparked a vicious cycle: first, our conversion rates would fall. Revenue would plummet.
Then, because Google took site bounce rates into account as a ranking factor, our top-ranked pages began to drop from the search index. Revenue plummeted again.
Simply put, we had no idea of the server requirements for a fast-running Magento installation. Now we do. My recommendation?
[bctt tweet=”Go with a proven Magento host who offers a strong VPS, and expect to pay up for monthly server costs.”]
3. We migrated ourselves
My co-founder and I are pretty tech-savvy guys. We code, we can reboot servers, we embrace the challenge of learning everything we can about the tech side of our business.
That said, we had no business migrating our own site to Magento. I’ve had a lot more experience with Magento since then, and have mastered the migration process — but even if I had all of that knowledge back in 2008, I shouldn’t have been migrating our site.
Why? Because as anyone who has read Michael Gerber’s E-myth can attest, owners should work on the business not in the business.
As the business owner, I should have been thinking of maximizing the value of my business — launching marketing programs, adding more merchandise, pursuing partnerships and new channels.
Instead, for months after and before our migration, I was only thinking about database queries, servers, and code.
None of that drove sales.
We viewed the migration as a fun puzzle that we were eager to solve, but we didn’t realize that that approach had serious business repercussions. Our eyes were not on the ball, and the top line suffered.
4. We changed too much of the site when we migrated
Magento comes out-of-the-box with exciting new layouts of category and product pages. We decided to implement these new layouts, believing they were better than our existing site layouts.
We removed the left navigation that was on all category pages.
We changed up the colors.
We added more features, like wishlists.
These changes had two effects:
- First, the added features and design elements added complexity to the migration, and the complexity added time to what could have been a quicker migration.
- Second, and more importantly, the new site confused our dedicated customers.
The result? Bounce rates on key pages stayed high even after we overcame our aforementioned performance issues. We saw our “checkout completion” rate plummet due to Magento’s cumbersome five-step checkout process.
We began several rounds of A/B testing to improve layouts and reduce bounce rates, typically with one new iteration per month.
The original layout won out on all A/B test, and we moved (back) to a site theme that approximated our legacy theme in April 2010 — five months post-migration.
My takeaway?
[bctt tweet=”Don’t add features when you migrate — strip them out. Make things simple, get them working, then add features back into the mix.”]
The Aftermath
Eventually, the migration dust settled. Flowers bloomed, we could shower again, and New York was beautiful.
The happy ending was that we were eventually able to reap the benefits promised by the migration.
We began to outsource more development work (freeing us up to work on the business), we added more features faster, and more and more of our chosen SAAS apps began to play nice with Magento.
In short, running and growing the business became a lot easier.
Best of all, two years after the migration, we were able to sell our company. Potential buyers liked the fact that it was operating on Magento because it meant they didn’t have to deal with our custom code.
So the last thing I want to do is to discourage anyone from migrating to Magento, or re-platforming in general. Just know what you’re getting into first—and do it more wisely than we did.
If you have any questions about our experience — or want to share your own — please share your thoughts in the comments.