Adobe Commerce Reviews

What is our primary use case?

How has it helped my organization?

What is most valuable?

What needs improvement?

Buyer's Guide

Adobe Commerce

May 2024

Free Report: Adobe Commerce Reviews and More

Learn what your peers think about Adobe Commerce. Get advice and tips from experienced pros sharing their opinions. Updated: May 2024.

DOWNLOAD NOW

770,292 professionals have used our research since 2012.

For how long have I used the solution?

How was the initial setup?

Which other solutions did I evaluate?

What is our primary use case?

What is most valuable?

How has it helped my organization?

What needs improvement?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

Which other solutions did I evaluate?

What is our primary use case?

How has it helped my organization?

What is most valuable?

What needs improvement?

For how long have I used the solution?

The Supercircuits website was running on an custom-developed ASP.Net ecommerce platform, which I inherited when I joined the company. Over time it had become increasingly unwieldy, hard to update, and buggy, and I was desperate to move on to a more modern ecommerce platform.

I'd been interested in Magento for a while as it appeared to meet all of our functional needs as well as being very affordable, and so, after a short period of due diligence, we embarked on an implementation of the Enterprise Edition.

Little did I know then, that it would take over a year to launch the site. But that's what happens when you combine a very small team, with a lot of operational responsibilities, with the requirement to integrate with an internal order management system that's about 10 years old.

Lesson learned #1: If you are about to embark on a major Magento implementation, I highly recommend making use of their consulting services at the outset. An architectural advisory will set you back a few thousand dollars but will make sure you pick the right architecture plan so that your implementation goes more smoothly. We did a lot of learning as we went, which slowed progress as you might expect.

Another challenging area was the migration of product data from the old site. Although we have a little under 1,000 SKUs, because they represent video surveillance equipment, they each have a lot technical specs along with various other complexities.

We had originally intended to manage product data programmatically via a centralized master data management system, but in the end, this proved too much to try and implement along with everything simply developing and launching the site.

As a result, we did not make proper use of attribute sets for classifying different product types, the results of which we are living with today (one day we will have the product comparison tool set up correctly). On reflection, we would have been better off entering all the product data manually and using the extra time to clean up the organization of our technical specs.

One area where we did make the right decision was not to attempt a complete site redesign at the same time. The relaunch was intended to be a "copy exact" — use the base Magento Enterprise store template and overlay our design on top of it. This worked pretty well, as the base Magento template looked nicer than our old site anyway, and we were able to make some further visual improvements in addition to this.

The good news is that we are now in a place were we can start making some more aggressive site design enhancements, now that the back-end heavy lifting has been completed.

A significant reason to move to Magento is its extensibility and the wide range of extensions that have been developed for it. If you can think of a feature, chances are someone has developed an extension for it. The great thing about this is that it reduces implementation time and cost for new features dramatically. I'm like a kid in a candy store with all the additional ecommerce capabilities that are now available to me.

Lesson learned #2: Not all extensions are created equally. I recommend limiting the number of extension vendors you use so that you can be confident in their quality and reduce the potential for code conflicts. We have mostly used extensions from aheadWorks and Amasty. Not only do they create great products, but the support of both vendors so far has been excellent.

Another reason I like Magento is that, as with Google Analytics and Wordpress, because the basic edition is open source it has a huge install base with lots of people developing for it, figuring things out, writing blogs and tutorials, and answering questions.

Consequently, if you have a question about or an issue with Magento, it's likely that someone has run into it and someone else has come up with a solution. The value of this wealth of information cannot be overstated.

One final downside of the extended development time for this website launch is that Magento Enterprise has moved on to version 1.12 while we are still on version 1.10. I do not intend to underestimate the effort to upgrade to the latest version, but it is something that we will need to tackle in the near future. If you don't, as you move further away from the current version, the cost and effort to upgrade just gets larger and more daunting.

A feature that we intend to take full advantage of over the months ahead is Magento's multi-store capability. At some point in the future I intend to have all of our sites running on the Magento platform which will be a huge efficiency gain for my team in terms of managing multiple websites and stores with a common product set.

One area where we have learned a lot is in regards to SEO. While we did all that we could in terms of onsite SEO, we (by we, I mean I) only redirected about 1500 URLs in our htaccess file. However, we have thousands of old product documentation PDFs which I did not have the time or will to get to before the launch which were still receiving links and traffic.

As I started seeing 404 errors pop up in Google Analytics for those pages and files, I began a multi-week process of updating the htaccess file, so that we now have over 6000 redirected URLs.

I am now keeping our htaccess file updated on a monthly basis by running the URLs being redirected to through Xenu's Link Sleuth, which lets you check an imported list of links (very handy). As redirected URLs break (for example, when products are discontinued and are removed from the site) I'm updating the redirect to keep it working. It's very manual, but worth it in my opinion.

We're now on a two-week release schedule for new features, which is aggressive but achievable. One module that we are replacing as soon as possible is our site search. Magento's default search algorithm is garbage. Incredibly, instead of using AND for an operator it uses OR, which means that the more terms you use to refine your search, the more results you get. It's completely backwards!

There is a truism when it comes to learning Drupal — once you've built your first site, throw it away and use what you've learned to build it again correctly. There were a few times along the way that I thought this about our Magento development process as there is certainly a learning curve and a 'right way' to architect it.

Now that we've launched, I've certainly got no regrets about choosing Magento as an ecommerce platform, and I'm looking forward to everything we can do to expand and enhance it.

Amazon Web Services (AWS) is the most popular and robust Cloud Hosting Infrastructure. Millions of sites and some of Internet’s most popular sites, portals and eCommerce Sites run on Amazon.

Deploying Magento Enterprise on AWS for serving millions of users and a large catalog size would require a deeper understanding of Magento and AWS.

This article talks about the architecture and points to consider while deploying Magento Enterprise on AWS.

The diagram below shows a recommended minimum architecture to deploy Magento for High Concurrent Traffic.

Given the architecture above the following points / settings  need to be considered while setting up the servers

1. Make your App Servers Stateless:
   What this essentially means is ensure that none of the user specific information like sessions, shopping bag contents etc are not stored on the server. The sessions storage must be moved to the DB or Memcache. This will allow you to easily add or remove an app server, without the online users getting logged out out or losing their shopping basket contents.
2. Do not enable sticky sessions on the Load Balancer:
   A load balancer is usually programmed to re-direct users to the app servers on a round robin method. However if sticky sessions are enabled then the load balancer will direct all traffic from one user to that one single server where his session is created.  While this works fine in most cases, there could be scenarios where the users connected to one server would be more active than the ones on the other, this would lead to an overload of one server while the other is relatively low on load. This would obviously affect the response times for users connected on the loaded server.
3. Ensure that the Media Folder is stored in an S3 bucket and it served via Cloud Front.
   I’ve seen many deployments where the media folder, which contains all the product images and other static content is being duplicated across the multiple app servers and is being rsynched each time a change happens. This is not ideal as the replication take times and while users would be able to see the images, the other would not be able to. The ideal way is to have the media folder on a S3 bucket and have it served via Cloud Front  (CDN) so that the images are served from the nearest node.
4. Put your CSS and JS also on CloudFront:
   Well that’s a no brainer,  all static content should be served out of cloudfront. Don’t forget to concatenate, merge and minify the JS and CSS files. Magento is notorious to have 12-16 different JS files. in their default and Enterprise themes.
5. Enable IOPS for your RDS database:
   Relational Database Service  (RDS) is usually the most preferred way to get your MySQL on AWS. RDS will make it really easy for you to get your database in Master Slave mode, and schedule automated data backups. However RDS can turn out to be a bottle neck when it comes to high read writes to the DB which Magento does a lot. This is because the RDS is essentially stored on a SAN which comes with its own latency problems. The one way to overcome that is to enable IOPS for RDS to make sure the app servers can read and write data to the RDS database sufficiently fast.
6. CPU over RAM:
   Magento users a lot more CPU than it uses RAM, so while choosing an Instance try and go for one that gives you more CPU power than RAM.
7. Use Memcache:
   User a Memcache server this will significantly improve the sites performance. Also importantly ensure you have a bank of memcache servers running and have it properly configured in Magento, else your memecache server can become a single point of failure.
8. Use Nginix instead of Apache:
   During most of our load tests, we notice the web servers being overworked most of the time and using most of the CPU power. Nginx has a much smaller foot print as compared to Apache and can server a significantly higher number of concurrent users than Apache.
9. Varnish can be a double edged sword:
   Many architects think simply throwing in a reverse proxy  like varnish before the app servers will help boost performance, that’s quite wrong. Putting Varnish in front of Magento Enterprise with full page caches on can actually be counter productive especially if Varnish is configured to server only images and static content. In many scenarios its actually good not to use APC instead of Varnish to improve speeds.
10. Disable xDebug:
    xDebug comes default within the Magento Installation and is quite useful for debugging the application during development. However it will slow down the site while running in production mode.  Significant performance benefits can be achieved by disabling xDebug in Magento.

With the above configurations we’ve been able to have our Magento Enterprise Portals server 50+Million visitors with under 5 seconds of page load times during peak loads.

Disclaimer: The company I work for is partners with several vendors

Valuable Features:

Room for Improvement:

Other Advice:

Valuable Features:

Use of Solution: