Is a single AEM instance best for your enterprise organization?

Most enterprise-level companies don’t have just one site in their portfolio they have 2, 5, 10, sometimes even hundreds. They could be scattered across multiple platforms or even worse on a server underneath the IT guy's desk. Choosing a platform for your company is key and having one that can handle all the sites in your portfolio is crucial.

AEM like many other platforms has a multi-site manager, making it easy to manage and maintain multiple sites in one instance. For example, they may have a site in Spanish, one in English, an e-commerce site, and a simple static site all on one instance.

Can AEM Handle multiple sites with millions of daily visitors?

Yes, it can! Where AEM stands out from other platforms is that it has the architecture to easily scale up. AEM comes OOTB with a dispatcher making it easier to cache content and distribute visitors to multiple servers so they’re not putting all the load on a single server.

This question came up with a recent Fortune 100 client, was among their portfolio was a site that hosted millions of visitors per day, and at the same time, they bought a company with a site that also had millions of visitors per day.

The client had two questions to answer: what platform is best for our business and do we go with a single AEM instance?

After many conversations both with the client and amongst our team, it was determined AEM was the right platform, and putting the entire portfolio on one instance made the most sense from a business perspective. It presented some challenges but in the end, they decided to migrate to AEM because of its ability to scale and sync seamlessly with other Adobe products they already used such as Target and analytics.

With a lot of hard work from our expert team, we successfully got both sites, as well as other sites from their portfolio, onto one AEM instance.

Should your business move to one instance of AEM?

Each business scenario is unique but from our experience with enterprise clients, I’ve compiled a list of factors you should consider when you're deciding whether to put all your sites on one AEM instance:

• What is your current infrastructure like? Does it have the ability to scale? Confirming that your current server setup can scale is key. Despite AEM’s inherent scalability, if all your traffic is going to one server it won’t matter. You should ensure your team has the ability to add additional servers if needed and perform load tests before you begin. In many cases scaling up is not a serious issue, but be sure to check with your DevOps team.
• Do you have a dedicated DevOps team? When we migrated this client’s one site that saw a million daily visitors to a new server, our DevOps team was very involved with the migration; helping to set-up and configure new servers, as well as a variety of other tasks like ensuring the URL structure was properly kept so SEO value wasn’t lost. The bottom line is, having a dedicated DevOps team is crucial to the success of the migration and continued support of AEM.
• What’s your analytics and personalization strategy? If you are migrating to AEM a key decision is whether to use AEM’s personalization and analytics features. We suggest you stay within the Adobe family, utilizing Adobe Analytics and Target is a major benefit because AEM easily syncs with both of them and brings a whole new level of integrated personalization features that would be difficult to reach with other software.
• What CMS is your current site built on? Depending on what CMS your existing site is on, sometimes you may just want to start from scratch when migrating to AEM. Often times you can either re-purpose some existing code/integrations or even migrate some of the content. This is an area you’ll want to work closely with your business and development teams to determine the best strategy.

In addition to the list of questions to ask, we’ve identified some pros and cons of moving everything to one instance. Honestly, sometimes it’s not the right decision to put everything in one instance. Depending on your situation you may want to split them across multiple AEM instances. Consider these points when making your decision:

Pros

• You can share global configurations. One of AEM’s great features is its ability to save versions of a page. If a content author on your team accidentally deletes an entire section of a page it can easily be reverted to a previous version and restore content. In addition to this, you have the ability to configure how many versions of the page you wish to keep. For example, If you wanted to change it from saving 5 versions of a page to 10 you can make the configuration in one location and all your sites will now save 10 versions of a page. There are many other global configurations possible within AEM however we wanted to highlight a practical example.
• Upgrading is easier. With any platform, you’re going to want the latest and greatest features but there can be a significant amount of work to perform the upgrade. With a single instance of AEM when you upgrade that one instance, all your sites are upgraded and available to use the platform’s newest features.
• Less long term development time. Your DevOps and development team will likely be ecstatic if all your sites are in one instance. It’ll be far less long term development overhead to maintain one instance as opposed to multiple. 
• Easy to share components or custom integrations. Your development team just created a component that sends user information to Salesforce. Since your sites are in one instance you can easily share this feature across multiple sites. But what if the configurations are different? No problem, with minimal extra development effort you can build the component to have varying configurations per site and direct information to different email distribution lists or Salesforce instances.

Cons

• You can share global configurations. While this is also a pro it could potentially be a con. It’s key that your development team strategizes in making changes to shared components. If someone forgets the component they’re modifying is used across multiple sites they might not have QA’ed what they changed across the sites and could have broken a piece of functionality.
• Multiple sites can go down if they’re in one instance. If something goes wrong on one side, it can and will affect the other sites on the instance. We had to address this for a client when one of their authors, who through user permissions was only allowed to modify one site, unfortunately, uploaded thousands of large files to the instance at once. The result was a total overload and subsequent system crash. It not only crashed the site the author was working on but had a cascading effect on all the sites that were on the same instance as well.
• Communication between teams needs to be in sync. Often times when you have multiple sites in one instance you’ll have various business units involved who oversee each of the sites. It’s imperative that they communicate effectively, especially at times when they’re planning on doing a large code/content deployment for any number of reasons. If another site is doing maintenance at the same time, this could cause the servers to be bogged down and the site could experience slowness or worse, go down.

Each enterprise has a unique set of business scenarios and no two are going to be exactly the same. What we’ve learned is that AEM can handle multiple sites with millions of visitors provided your server setup is right. It’s important in any scenario that you take the time to strategically plan what you're going to do upfront, ensuring your business and development/DevOps teams are in sync throughout the process. If you have any questions about projects we’ve done in the past or just want to reach out we’d love to hear from you!