If you use Adobe Experience Manager On-premise (AEM On-premise), is it wise to maintain this capability?

In my prior article “Is AEM as a Cloud Service Right for Your Business?” I listed four reasons why a current on-premise AEM user should move to the cloud. But those reasons do not apply to all businesses, because the cloud is not for everyone.

This article lists four restrictions that may prevent you from transitioning your AEM On-premise solution. It also discusses the steps that companies should take if they maintain their existing on-premise solutions.

Four Reasons for AEM On-premise to Remain On-premise

Here are four restrictions that may prevent you from transitioning your AEM implementation to AEM as a Cloud Service.

Data Governance Requirements

Some organizations are subject to stringent data governance requirements. Perhaps they are in a highly regulated industry, such as finance or healthcare. Perhaps they manage other types of sensitive data.

While there are cloud deployments (such as FedRAMP-approved “government cloud” services) that can handle cloud storage of certain types of sensitive data, some organizations may prefer to control this data themselves via an on-premise deployment in which the user provides and controls the hardware, software, the highly-trained personnel, and the facilities. If a user is knowledgeable of the data governance requirements, it may prefer to exercise the complete control possible via an AEM On-premise installation.

Customization Needs

Some organizations may require significant customization capabilities. While AEM as a Cloud Service allows customization, there are limitations. These arise primarily because Adobe is responsible for managing both the hardware and the software hosting AEM as a Cloud Service, limiting a user’s customization capabilities.

For AEM On-premise, the user is responsible for all aspects of the installation, including hardware, software, and even the timing of upgrades and updates. Because of this, the user has much more leeway in customizing AEM to meet their specific needs. Thus, if a user requires extensive customization, it may be better to remain on-premise.

Legacy Implementation Investments

Some organizations have already invested heavily in their on-premise implementations. They may have contractual commitments for the hardware and software their on-premise systems use. They may have hired support and security personnel to maintain these implementations. They may have invested in specialized facilities to house the on-premise equipment.

They lose the value of these investments if the organization transitions to AEM as a Cloud Service. So even if a move to the cloud would provide significant technological advantage, it is less than the perceived financial losses of “throwing away” the investment in legacy hardware, software, personnel, and facilities.

Interfaces to Legacy Systems

Some organizations need to interface with older legacy systems that are not cloud compatible. These older systems may not have modern application programming interfaces (APIs) and may need to rely on older interface techniques to communicate with your AEM On-premise implementation.

While it may be technologically possible to develop cloud interfaces to these legacy systems, it may prove to be easier and less costly to maintain the existing interfaces and infrastructure by keeping the legacy AEM system. This is another instance in which the financial costs may take precedence over the technological advantages.

What to Do If You Don’t Move to the Cloud

So perhaps your organization won’t transition to a cloud solution. You are not the only one. But there are tasks you need to perform to ensure your AEM On-premise solution continues to serve your organization.

Perform an Implementation Health Check

Analyze your system and its health to see how it is performing. For example, here are the questions that KBWEB Consult asks when we perform an implementation health check for our customers:

  • How is the current AEM implementation performing? Are there performance issues such as slow loading pages that are hobbling your AEM On-premise implementation?
  • What version of AEM are you running?
  • Have you previously attempted to upgrade your implementation?
  • Afterwards, why did the implementation stall? Were there blockers or technical gaps that forced the abandonment of the upgrade?

Define a Project Plan for Improvement

If your implementation health check (or equivalent) reveals shortcomings in your AEM On-premise implementation, create a project plan to fix these deficiencies. Again, this is a standard part of KBWEB Consult’s projects for our own customers. Four tips:

  • Define “SMART” goals that are specific, measurable, attainable, relevant, and time-bound.
  • Include dated milestones to track progress. If you do not know where you are going, you will end up someplace else.
  • Ensure that you have the available resources you need for the project.
  • Design your project in a way that minimizes risk. For example, U.S. retailers should not roll out a new system the day before Black Friday.

Upgrade, Upgrade, Upgrade

You not only want to upgrade to the latest AEM On-premise version, but you also want to upgrade other portions of your system to provide the latest features and the latest security.

Of course, it is especially critical in a system with legacy components to ensure that all components are compatible with each other.

Do You Need Assistance with Your AEM On-premise Implementation?

KBWEB Consult practitioners offer experience with both AEM as a Cloud and AEM On-premise implementations. We can analyze your existing implementation and assist with implementation projects, even those that are stalled.

I am in Las Vegas for the Adobe Summit this week (March 17-20) and would be happy to meet with you to discuss your needs. Book a meeting with me in Las Vegas!

–