I’m working on our Magento 2 upgrade right now, two months before its release. Why am I so bullish, when so many other merchants and agencies are taking a “wait and see” approach? Risk and return. It’s that simple.
Anyone who’s lived through as many painful upgrades as I have is nervous about change. When your business depends on an operating system or software platform, you never rush to upgrade. The initial version will be buggy. Once you upgrade, it’s hard to roll back. You don’t know what the new version is really like before it’s released. So you wait until the release. Then you check it out. And you wait. You wait for all the idiots who rush in to find the bugs. You wait for the company to issue patches. Then you start to plan an upgrade. You roll out slowly. No rush. Why break what’s working?
I’m not going to say that I think Magento 2 is different. It probably isn’t. But for some merchants, in some situations, Magento 2 has a slightly different risk/reward profile.
Do You Currently Have a Project Backlog?
If you’ve currently got a backlog of projects you want to implement on your Magento site, or even if it’s just a wishlist of features you plan to develop in order to customize Magento for your business, you’re like me. My company has a number of projects we’d like to push forward to customize and extend Magento, integrate it better with some of our other systems, and push forward some marketing objectives. This is actually what initially made me start to take Magento 2 seriously.
One of the hidden costs of pushing forward with active development on Magento 1 after Magento 2 comes out is that, if you later transition to Magento 2, you’re going to have to redo all of those projects on the new platform. The projects might go faster the second time around. Or they might go slower since you’re learning the new platform. But at a minimum, you know you’ll pay to develop them twice, more or less.
What’s the Risk of Upgrading Too Fast?
If you upgrade too fast, though, you risk potential issues with the new platform. What do you do if you launch before other people have vetted it thoroughly and encountered all the bugs? The worse case is that you have a non-functioning site, incapable of processing orders. That’s pretty bad. But since this is a risk, it’s not certain. Let’s say there’s a small probability of catastrophic errors.
How big is that risk? Wow, that’s really hard to gauge. When Magento released the 1.9 responsive web design theme at Imagine 2014, they knew there would be some resistance to trying it out. But they also knew people really wanted the additional benefits of going with a new responsive theme. So they made sure that when they released it, they’d also profile early adopters who already launched it in the beta program. This is what Magento is doing with the Magento 2 launch.
Magento picked a group of firms, diversified by industry and geography, and started working with those merchants and some of their partners to launch these sites on Magento 2 early. You can bet that when Magento 2 launches, there will be a handful of sites already running Magento 2.
My point with this is not that Magento 2 will be fully vetted, free of all bugs, and perfect. My point is that there will not be fundamental problems with the platform that cause it to not work at all. You might still have problems, because of some special cases you’re dealing with in your business. But the platform itself will be solid. And if you do encounter bugs in your deployment, it’s likely they will require only minor tweaks to fix.
How to Balance the Risks?
Think back to the previous risk, that if you don’t go to Magento 2 early, you’ll be doubling your development cost and time. What’s the risk of that? Well, if you assume you’re sticking with Magento for a while, it’s a near certainty, or a risk with nearly 100% chance of occurring. You will re-develop all your customizations from Magento 1 on the Magento 2 platform, whether it’s this year or next, or the one after.
How do you balance the small risk of catastrophic failure against the almost certainty of doubling your development costs from this point forward? There’s no right answer, but I’ll tell you my perspective, based on my company’s goals and experience.
If I can reduce my mid-term development costs, and prevent rework in the next couple of years, it frees me up to push forward even more aggressively on growing our business and becoming more competitive. That’s where I want to focus. If I can mitigate the risks of moving too quickly and make sure that my business doesn’t suffer any catastrophic failures from early adoption of Magento 2, I think it makes sense.
Mitigating Risks
Minor problems that impact a few customers would be irritating, but my largest concern is with some catastrophic failure of Magento 2. How could that risk be mitigated? The thing to remember is that a Magento 2 deployment is a new site. Until you cut over from the old site to the new site, the old site is still up and running. And guess what? After cutting over, the old site is still running. It’s just not being pointed to by your Domain Name Servers any longer. You’re going to deploy your Magento 2 site on a new server and at cut-over, you’ll change DNS so www.yourcompany.com points to the Magento 2 server. The easiest way to mitigate the risk of your new site having a huge failure is to just keep the old site live. If anything goes wrong, point the DNS back to the old site.
There might be a few issues with this, but they’re relatively easy to solve, depending on the size of your company. If you cut back over to your Magento 1 server, inventory levels would not be perfect. This might cause problems for companies that don’t maintain much inventory and depend on extremely accurate counts. Another issue would be with order numbers and accounting issues. Just changing the order increment ID on the new site to skip a bunch of order numbers would probably solve this. Worst case, your accounting team has to deal with a few order numbers out of sequence if you cut back to your old site because of some bug. Larger companies might have more issues with things like this and complex integrations with other platforms. But for a small or mid-sized firm, this seems like a fairly simple way to mitigate the risks.
So What?
If you can mitigate the risks of an early adoption of Magento in a way that’s acceptable, then you’re really left with one risk you can’t walk away from. The risk of delaying an upgrade… What will it cost you to put it off, in time and expense to redo everything you’re working on from this point forward.
And that’s what I keep coming back to. Perhaps if I wait a bit, the cost of migration will come down a bit, and I can learn from other people’s mistakes. But my company doesn’t have a crazy set of Magento customizations. And we’re working hard to simplify what we’ve got. What we do have is a wish list that’s a mile long, and a desire to make good strategic choices to maximize our profitability over the long run. Assuming Magento 2 is solid when it is released, or that the bugs are minor and quickly addressed, we’re better off pushing forward on the new platform. We’re not remotely considering a move away from Magento to another platform, so this makes sense for us.
Bottom Line
Bottom line, we’re working on our Magento 2 implementation now, with our small internal team. If we encounter any major problems, we can always choose to forgo a quick upgrade and wait. If we launch and encounter problems, we can cut back to our Magento 1 site.
But we’re certainly not going to give our competitors an advantage by letting them move forward aggressively while we sit and wait. Business is risky. Rationally balancing risk and reward is tough and never perfect. Sometimes we’re right and sometimes we’re wrong. But this risk is one that I think will pay off, at least for our company.
If you’re a Magento merchant moving forward with an M2 upgrade, stay in touch. It’s always good to share experiences and help each other.