It’s June 2020, and the “closing bell” of Magento 1 support termination has rung. Although the deadline has been previously postponed several times, this time it’s final: online stores that are built on Magento 1 won’t be supported any longer. While they’ll still be functioning, they won’t be getting any more updates (and YES, this regards the crucial question of security patches and means that such stores will be deprived of new functionality). The bottom line, there’s no more time left to put the process off. And due to that, many Magento 1 store owners who haven’t begun their migration yet are biting their nails in anticipation of what they are to encounter ahead.
Without a doubt, you won’t make it without a devoted team who’ll provide you with professional Magento 2 migration services. But what are the possible stumbling points that you can face along the way? In this post, we bring you a detailed explanation of what you can expect and give recommendations on how to prevent unfortunate turns of events.
Before we jump right over to the possible issues that may occur, let’s dot a couple of “I’s”. As stated earlier, there are many reasons why it makes sense to migrate your Magento 1 store to Magento 2. As such, you wouldn’t want your website to lack behind in terms of modern features that are so vital in the ever-changing and progressing world of eCommerce. You surely don’t want your store to be unsafe either, as you’re legally responsible for safeguarding the data and contact details of your customers (data leaks on your fault can result in large fines, that’s how it works).
So although the idea of keeping things just as they are for now is tempting (after all, your M1 store works pretty fine as it is), you’ll still have to eventually make the move from Magento 1. Of course, this means investment from your side, but it’s a great chance to:
So why later than sooner? Wild guess: because you’ve most likely heard a lot about the struggles and long time frames that it takes to make the move?
Fair enough, the process is as far as easy as it can get. Thinking that the migration is some simple copy-paste is a common misperception. The root of the problem lies in the fact that even though Magento 1 and Magento 2 differ in a single digit in the name, these two versions are completely different from each other on fundamental levels. At times migration to M2 can basically mean the same as building the entire thing from scratch (what store-owners often tend to do). It takes a lot of coding, untangling data, bug fixing, testing, upgrading, and implementing custom solutions to get things done the right way.
The mentioned above are just some of the things explaining why the process is hard, but what can cause serious roadblocks for your worry-free migration?
As simple as this may sound, it’s true. Despite the fact that there are many Magento developers out there, finding those specialists who are competent in both Magento 1 and Magento 2 is not an easy task. Especially keeping in mind that, by all means, you want people with previous migration experience to handle your store.
Things can go completely wrong just because those who you’ve entrusted to work on your case might not have the needed expertise that’ll be equal both for M1 and M2, who might not have the necessary knowledge of the core differences between the platforms, and who don’t really know how to deliver a seamless migration.
You don’t want your store to be the field for trial and error, this is a waste of your money, time, and resources. So how do you choose the right people? Pay special attention to:
Avoiding the planning phase as a way to “win time” is a rookie mistake. Making up your mind regarding what you want after the migration process has already started always results in bottlenecks. If doing so, you:
Hence, it follows that with a clear vision of the result and a mapped out journey, you can count on better communication and migration. Tip: get your development team on board as you plan the work ahead, this way, you’ll all be on the same page.
Practically every store makes use of external plugins, third-party extensions, and even custom modules, apart from the functionality that’s offered by Magento out-of-the-box. When it goes down to the work with module migration there are many things to be handled:
But these four points only cover the cases when that can be done with the currently used modules. If there are no analogs for them or when there was a custom-designed solution on Magento 1, this may result in the necessity to develop new custom solutions. And custom development takes time.
Moreover, migration is the moment when store owners generally want to recalibrate their website and introduce innovations. Meaning not only the migration of old modules but a pack of new ones that’s been added on to the top of the pile, resulting in… Yes, you’ve guessed correctly, additional hours for implementation, testing, etc.
How can you solve this problem?
The scope of data for migration is much bigger than you think. It’s not just the modules, it’s not just your product inventory. We’re talking about all of your information that has been collected over the years: orders, clients, logs, the list can go on for good.
At times barriers arise when stores have product inventories kept in external custom systems. For such situations, there can be a need in custom transfer logic, and that’ll gobble uptime. Other backpedaling situations that could be mentioned include dealing with the required data reorganization or re-systematization. Not to mention the long hours spent on fishing out what to dispose and what to move to Magento 2.
Again, here you can confront multiple progress stoppages. The best advice is to make sure that this stoppage isn’t you! Be open to new enhanced solutions as opposed to sticking to the way things were done in the good old days. Ask yourself questions like: “Are logs from 2008 really that important to the business to be transferred?”
As mentioned before, many things can influence how long the project takes: bad planning, poor team performance, unexpected difficulties with implementing new features, or shifting what’s been accumulated over the years. So it’s no surprise that the estimated deadlines are often pushed forward. Sometimes this isn’t critical. The question is how far are they pushed?
When agreeing with your developers on deadlines, you’re most probably counting on them to be met. Most often, expectations might not be fulfilled due to either broken promises or real issues that have occurred in the course of work.
How can this be avoided? Don’t forget to be involved in the process after you’ve agreed on the migration but don’t push it over the top. Your presence matters but it shouldn’t be distracting. Talk to your developers, ask for updates on what has been completed, request intermediate results, establishing milestones that help a lot too.
Earlier this year Google began including AMP listings into its mobile search results. AMP, short for Accelerated Mobile Pages, is a specification for creating slimmed down pages for mobile devices. It’s a subset of standard HTML but with restrictions. In addition, Google caches AMPs on its own CDN to provide the fastest retrieval possible. Any AMPs appearing in Google Search results are linked to these cached pages.
You may be asking yourself why we need such a thing when mobile phones are already capable of displaying “ordinary” websites. It’s a good question, and admittedly that was my first question when I first learned of AMP. The AMP project says the purpose of AMP is to give mobile users a better, faster web experience. But what’s wrong with the current user experience on mobile phones? Is it really bad enough to warrant an entire new web page specification when we already have HTML 5?
phpMyAdmin is a handy tool for administering mySQL from an easy to use web interface. However, leaving such a powerful tool open to the entire world can be downright dangerous and is something that should be avoided if possible. Ultimately it’s best to keep it off your production server (or any other server you care about). However, if you absolutely must use phpMyAdmin, you should restrict who can access it. Below is a quick and easy tweak that will only allow access to it from a specific IP address. This tweak assumes an Ubuntu LAMP stack, but should work fine on any Linux distribution, although paths may be different.
Recently, I needed to have a few specific categories show the products in grid mode, while all the other categories show products in list mode. This should be straightforward since the products that appear on a Magento category page can appear in either a vertical list, or in a grid. And, depending on how Magento is configured, the user can choose which view to display the products in.
AWS makes it easy to take snapshots of your EBS volumes. However, if you have many volumes, a way to automate and rotate snapshots becomes essential. There are many solutions out there to handle automated snapshots. One such excellent solution is the ec2-automate-backup script. Setting this script on a cron job, you can snapshot all your volumes in a specific region. Below is how I’ve set this up.
I have multiple EBS volumes attached to multiple EC2 instances. I needed a way to take a daily snapshot of all volumes. In addition, I needed the snapshots to rotate, such that only the last 7 days worth of snapshots would be kept.
I chose to create a small EC2 instance specifically for running ec2-automate-backup from a cron job that will backup the volumes of all my production instances.
WordPress can make for a great CMS, but sometimes it’s not always feasible or practical to use it for your entire site. One common scenario is to use WordPress for a blog that runs along side a site built with a completely different technology. However, a problem arises in this situation: What if you want to display blog posts on your non-WordPress site?
The present trend is that of mobility and the same applies to computers as well and that is the reason why more and more people are opting for internet enabled smartphones as they help them stay connected even while on the move. However, this has posed a certain type of problem for websites and website developers as many of them are not mobile friendly and hence not accessible through the mobile. The inability of websites to connect with the customers through mobiles could mean a loss of customers, which no business can afford. Therefore, website owners and developers have to work towards creation of websites that are available for the mobiles as well.
However, the task of creating or building a mobile version of the website is not very difficult as there are several tools that ease the process of creating mobile versions of websites. Some of these tools are discussed below:
On the Ecommerce Outtakes blog, we talk a lot about what not to do online. In fact, our main focus is to point out where websites go wrong—with the intent, of course, to help improve the e-commerce experience across the web. One trend we’ve been noticing a lot lately is a lack of good filtering and sorting options. It’s a widespread e-commerce epidemic, and it’s high time we cured it.
Page loading time is crucial to keeping visitors on your site and
maximizing conversions. Studies have been done that show the maximum
time people are willing to wait for a page to load is less
than 5 seconds. Make them wait more than that, and it’s game over.
They’ll hit their back button, never to return. It’s vitally important,
then, to make sure your web site is loading as fast as possible.
Sure, having a super-beefy server helps, but one important aspect of
having a fast loading website is reducing the size and number of your
page assets as much as possible. This can be a real challenge within the
current state of the Web. Web pages are becoming increasingly more
complex globs of code that require a huge amount of assets to display
and function properly. In addition to the plain old html, a ton of
background for the page to fully render in a browser.
“What’s the big deal?” I hear you ask. “All my visitors are on
broadband, and the js/css/images are only a few KB extra – hardly a drop
in the bucket!” Now, this may very well be true. However, the fact is
that the actual size of your files are only a small part of the overall
cost incurred on a page load. There is a much more subtle bottleneck
that has nothing to do with file size: The maximum concurrent connection limit.
This is a limit the browser enforces which dictates how many
connections can be open simultaneously to a single server. Even if
you’re on a super-fast connection, your browser will still limit the
maximum number of files you can download at one time. This number varies
from browser to browser, and may change slightly depending on connection
speed and web server configuration. The actual values for Internet
Explorer, Firefox, and Chrome are below:
It can be helpful to think of a concurrent concurrent limit as the end
of a funnel that your page assets pour through. Naturally, the more
assets you have the longer it takes for them to get through the funnel.
Making your assets smaller helps them pour through faster, but still,
only so many can go through at once no matter how small they are. The
key is to combine them into as few files as possible, thereby reducing
the connection limit bottleneck. Making your files smaller AND combining
them is a win-win situation. Smaller files + fewer connections =
faster loading site.
To “minify” a file simply means to strip out all the “human readable”
parts of the file such as indentation, line breaks, comments,
extraneous whitespace, long variable names, etc. E.g all the stuff that
makes it easy for a human to read, but which a computer couldn’t care
“Same Thing” Sickness
One thing that SEO’s hate about web developers has to do with the way they execute or fail to carry out a very specific request.
A case in point: An SEO requests a developer to create a 301 redirect between pages. The developer does a meta-redirect or a 302 redirect citing that it’s the “same thing”.
From the developer’s perspective, it’s the same thing for the user, but from an SEO standpoint, it affects the search engine rankings.
The Death of Optimization
Developer skills and SEO techniques go hand in hand, so when if a developer fails to do their job, then it doesn’t matter what the SEO team does. Even with a copy of Google’s secret algorithm in hand, the site won’t rank if the site won’t work.
A case in point: A client implements some redesign elements. Suddenly, traffic drops by 30%.
The problem: Many of the pages don’t load like they should and the ones that do load show 500 server errors. The developer failed to spot the errors during the development process.
The result: 3 weeks of seriously diminished traffic.
The “I Know SEO” Syndrome
This is a contagious disease that developers get that can quickly spread to other developers. If you have ever heard a developer say something like I’m pretty good at SEO, it can usually be translated into I’ve read a little about SEO and therefore I pretty much know more than you do.
But wait a minute, SEO’s. You aren’t immune, either. There is a related syndrome called “I can code”.
A case in point: An SEO expert successfully builds a Word Press site and suddenly deems themselves a web developer.
The Real Problem
At the root of the culture clash between coders and SEO’s are their driving philosophies. Business classes that teach search engine optimization focus on uniqueness. After all, differentiating yourself from the competition is a good thing. On the other hand, computer science classes center on making everything the same. Each discipline takes a different approach to reaching the same result: stability and efficiency.