MageCoreInc Blog


Magento 2 – First Look and Key Differences between 1.x and 2.0

Magento 2 has finally been released this month after several years of active development. Magento 2 was initially conceived by Yoav Kutner in 2010 while still with eBay so it is fitting that we take a look back on the results. In this multi-part blog article we will work to answer the following questions while getting familiar with the Magento 2 release:

  • What improvements does Magento 2 brings to eCommerce?
  • What are the key differences between the very popular Magento 1.x version and the very new 2.0 version?
  • Which system is better to choose when you start with eCommerce?
  • Should I redeploy on an existing platform?
  • Should I upgrade from Magento 1.x version to the latest 2.0?
  • Were all major 1.x problems resolved with the 2.0 version?

These and many other questions are going to be answered in the series of Magento 2 articles published on our blog in the upcoming weeks.

A first look at Magento 2

This look is based on published marketing materials and test installation on our local environment. At first glance these items present a picture of a mature project. The documentation and supplied materials, which cover specific details, are in place and available to use for “quick start” purposes. Developers have easy access to the Community Edition code and the application can be deployed and used in production without any critical issues upon our installation. Magento learned its lessons from 1.x and focused on key bottlenecks when developing 2.0: performance, scalability, and usability.

This post will answer two of our initial questions about Magento 2.0:

  • What are the most important architectural improvements focused on system performance and scalability?
  • What are the key differences from a product and features perspective?

System and Performance

Page Cache

Magento 1.x frontend performance for sites with high traffic rely heavily on a few key concepts. Proper server configuration, using established code principles, and caching wherever possible are all critical to keep servers from bogging down under redundant requests. The cache layer in 1.x evolved and at some point developed into the Full Page Cache (FPC). This feature was available in the Enterprise Edition (EE) and resolved many problems related to slow page loading time, but introduced others (cache invalidation rules, cache effectiveness, size). With these known FPC issues, and lack of this solution in Community Edition (CE) products, many technology partners began using Varnish as a proxy cache solution. This resolved Magento’s native page cache bottlenecks and allowed partners to deliver high performing websites. In Magento 2 Varnish was selected as the out of the box page cache solution. In theory there is no integration effort required other than standard configuration. This appears to be a great decision and in the following weeks we’re going to verify that it is as plug and play as possible.

Partial Indexing

Reindexing database data is always a resource intensive operation that affects daily business, especially in the case of large catalogs. In Magento 1.x incremental indexing improvements (partial indexing) were introduced in order to address this issue and allowed for the stable operation of large projects on the EE version. This architectural improvement was transferred to the 2.0 project and is now available for both CE and EE versions. Hopefully this will be a major step forward for all community users looking to use CE with a larger catalog. This is a major concern in cases where businesses alter product data on a daily basis.

Database Scalability

One of the biggest bottlenecks for very large deployments with Magento 1.x was the database (write direction). It was not easy to customize Magento to run on multiple databases or even split specific operations such as: checkout, catalog, and customer to run on a separate master database with background data synchronization. Out of the box Magento 2.0 offers the option to use three separate master databases for different functional areas allowing users to separate the load for checkout, catalog browsing, order management, etc. Although it is available only with the EE version, this promising feature is suitable for merchants struggling to support their peak traffic during holiday season. In later articles we will measure how easy it is to deploy and how effective the solution will be.


Security in PHP applications is all about developing a code according to best practices, testing application endpoints against typical attacks, and following security practices. Magento 2.0 introduces many enhancements into the base framework enforcing some practices to be used. Preventing cross-site scripting (XSS) attacks with framework changes or by enabling SHA-256 password hashing for both CE and EE versions. In 1.x it was only an EE version feature so this is a major improvement to security.

UX and Functionality

It’s no secret that the 1.x version backend design is old-fashioned. Some users would go as far as replacing the backend theme with some Community extensions available for that purpose. Magento 2.0 addressed this issue in a big way. Using Magento 2.0 it’s clear that this is a modern application.

It is important to emphasize here that a simple skin change would not be a substantial enough of a change. Magento 2.0 offers layout changes and information architecture to improve user experience. When using 2.0 you get the impression that functional elements are easier to find. For example; the user does not need to click through nearly as many elements to create a product.

One of the very interesting backend changes is the ability to add/remove columns to available grids based on entity attributes.


Magento 2.0 supports almost all 1.x features, however most of them have improved workflow and adjusted functionality. The UX improvements for product creation look to be very interesting from the merchant and user perspective and touch areas such as:

  • Product view information architecture
    • All key product attributes are now available on one single screen with all the important product attributes (like “Product Online” status) properly distinguished
  • Multiple product templates
  • Category creation from the product page and ease of creating complex product structure (configurable, grouped, etc)
  • The ability to create product attribute from the product view page
  • It’s now possible to reorganize product attribute collections and change sets after the product was saved


It doesn’t appear that we will find new marketing features in Magento 2.0. A noticeable change is definitely the simplified layout and information architecture – items are better organized and have meaningful labels. However, there is no additional functionality such as promotion rules and newsletter templates.

Order Management

A major change was expected in the order management functionality. For example:

  • Introduction of workflow steps
  • Ability to edit items under orders and payments. This no longer requires the order be canceled first.
  • Easy customization of an order invoice so that it can be used as legal document

Unfortunately none of these improvements were implemented in Magento 2.0 and, except some layout and design improvements, it appears not much was done to clearly differentiate 1.x from the 2.0 product. We understand this is just the beginning and hope improvements to this section will be introduced in upcoming releases.


The one page checkout in Magento 1.x is known to be not very usable as users have to submit a few steps before they finally get to the order confirmation page. There was a need to improve that native flow and often a need to enable a one-step checkout extension. In fact, checkout customization is one of the most popular requests from MageCore clients. This has been addressed with the 2.0 release. Magento 2.0 introduces a two-step checkout – one step to add order data and the other step to review and complete the purchase. These new flow is definitely a huge improvement over 1.x.


Only PayPal,, and Braintree payments are available in the 2.0 product. If a merchant wishes to use some of the 1.x payment integrations then customization will be required.

Maintenance and Operations

No significant changes are available in 2.0 except information architecture changes. Navigation items are better organized and rules and permissions work the same (using the same logic).


Once technology companies start using the 2.0 product as a base platform for new projects we expect to see noticeable amounts of 1.x extensions being refactored for 2.0 usage. There is no backward compatibility and every 1.x extension will need to be refactored to be compatible with the 2.0 version. Beyond that, there is not much we can share here – simply that there are just a few 2.0 extensions available compared to the amount we have with the 1.x version.

We are planning to pick the most commonly used extensions used by MageCore clients and see if these extensions have a version available for Magento 2.0. A separate blog post will be published on that topic.

Development and Maintainability

Although this paragraph is added at the end of the article, it can be one of the most critical elements for technology partners currently developing on Magento 1.x. The Magento 2 architecture is different from 1.x and there could be consequences for technology partners who are slow to adopt.

Magento 2 introduces many new concepts to system architecture, primarily to address key requirements for extensibility and modularity. Adoption of the Coding Standards for PHP, using Composer to manage application dependencies, and separating application layers (view, service, domain, persistence) are good direction. This is especially true when seen from the Oro perspective as they are already using the Symfony framework where many of these concepts are in place. On the other hand, it adds additional complexity to the platform and might be overwhelming for 1.x developers. There is no question that these architecture changes will affect project delivery timelines and team velocities, the question then becomes how much.

Magento 2 is a completely new platform compared to Magento 1.x. and has its own learning curve for developers. This is also why we don’t call the process of migrating from Magento 1.x to Magento 2.0 an “upgrade”, but rather a “replatforming”. Which, of course, comes with the cost.

You will be redirected to [title]. Would you like to continue?

Yes No

You will be redirected to [title]. Would you like to continue?

Yes No