Adobe Experience Manager Reviews

Integration is the most valuable feature because it is the main selling point for customers.

It helps standardize the branding of pages across an enterprise by locking down what can be entered into page types.

The idea was to make it easy for the marketing teams, but it requires engineers who are hard to find and expensive to employ.

I have used this solution for three years.

Overall, there were no stability issues; I have found bugs and workarounds, like on any other platform.

There were no scalability issues as such. It is hard to auto scale on AWS because of the customization, but since AEM is an enterprise-level platform, sites can be provisioned for worldwide use.

The technical support for AEM has to be at a very high level to begin with, so, I've worked with some amazing people; Adobe hires some great people. Working with Adobe technical support was great, although it can take time for the back and forth, as they have to understand the details surrounding your issue.

I used to make WordPress sites. AEM is a CMS and so much more, it requires more of my skills. Companies usually switch because they can integrate more marketing tools easily with their website. Many companies have migrated from SharePoint.

The setup was complex due to the learning curve. Integration requires some planning ahead and communication between various IT factions. Often, the digital marketing departments may feel isolated.

First, you're going to spend a lot more than you think.

I never purchased it but yes, it's very expensive, so companies have to think about how to justify the cost and have to look at alternatives.

Have a good relationship with budgeting and your various in-house IT divisions; have them understand the needs of digital marketing.

Ease of use for content authors and tight integration with Adobe Marketing Cloud Products like Target, Analytics, Campaign; a complete solution for organizational digital marketing needs.

My organization is a services company.

Speed of web response for high transaction websites.

Those websites which have a lot of user interaction in terms of forms submissions, live comments, etc.

Over five years.

Rarely.

No.

Six out of 10. The tech support from Adobe is slow to respond and takes a lot of time to fix product related bugs.

No.

As simple as double clicking a .jar file.

Depends on usage and number of sites to run, but pricey.

Full knowledge with its technical stack.

The following features are most valuable:

• OSGi bundles capability
• DAM (Digital Asset Management)
• E-commerce capabilities
• Campaign management 
• Components re-usability for making pages

Creating new pages that have similar aesthetics to existing pages does not require any new development requests. An author/user has many flexible options for making new pages. In addition, by adding new pages to an existing website, the author/user saves time and money.

You do not need to create new pages for different kind of products; a single page works for all product kinds and types, by using the same product template page like on the sample site Geometrixx.

Integration with MongoMk for storage, in place of TarMK, is not efficient. But if it becomes efficient, this improvement would solve storage problems for many of AEM's big clients.

I have used this solution for three years.

AEM, when setup using Mongo, rapidly gains size. Hence it consumes a lot of storage space in a very short period of time.

The initial setup is pretty straightforward, as it requires running a single .jar and deploying code and content into it. For production, the combination of author and few publisher AEM .jars, the dispatcher, and few AEM configurations needs to be fulfilled.

The cost can be high. But for large websites with a lot of dyanmic data like e-commerce, or for clients looking for user-data based campaigning, the solution can be very efficient in the long-term. 

This product has a lot of valuable features.

• CRXDE that really allows you to browse static content data and change it on demand at runtime. From the business perspective consider this feature as the online DB viewer.
• General framework architecture – a group of instances (authors) where content is co-authored and a group of separated instances (publishers) via which content is available on the Internet.
• Publication – you just press Activate on a page and then your changes are sent to all publish instances, so complete and clear separation of what is to be published and what is actually published.

• App SideKick – a blue window that allows you easily to drag and drop components on the page.
• Content Finder - you activate it via #cf in your url. It is the left blue window on the page that allows you to drag and drop DAM assets. Actually, this is the part of CQ that connects your pages with DAM.
• Admin console given by Apache Felix.
• JCR – place to put static content available via CRXDE for users.
• Mod_disp – special module for WWW servers.

• JCR access – lack of transaction from development perspective
• Memory leaks - problems related to OSGi and bundles management
• Lack of support for InteliJ and NetBeans when it comes to IDEs
• Very protected documentation with very limited number of solutions available on stackoverflow.
• Sometimes developer did not know why some files were still being cached by dispatcher. This Mod_disp is just very much black-box-like solution.

From the business perspective:

Pages were very related to each other when it comes to behind the scenes JavaScript dependencies and their internal structure design. Content managers were not able to understand why they had to publish some extra related pages to the one just they wanted to publish. It is a problem of transitive JavaScript dependencies. This approach generated a lot of frustration. Actually, in my opinion, the concept of JCR should be hidden from content managers.

Memory leaks - yes that really impacts overall stability. Actually, it is the problem of zombie OSGi services.

No - it is better than ATG, Magnolia, etc. It is a first-in-class product.

Very very poor.

Yes - Magnolia and Joomla, Liferay, etc. I switched my working places and it was just the main product used in the department.

Setup of localhost dev. environment. Very complex. Actually you cannot start development alone. Somebody must introduce to the concept of Sling and JCR etc. Very, very hard intro.

CQ is very expensive. The licensing model is not clear.

CQ is expensive but the worth money. If you are looking for a free or cheap equivalent use Magnolia CMS. Very similar in the general design idea.

If you install one of their sample web sites on exactly one machine, it might actually work.

This product is not open source, and thus, you are at the mercy of poor documentation and support personnel, who generally lack enough experience to solve difficult problems. Their API has poor coding standards, and you will find just about every Object Oriented anti-pattern in their exposed API.The product includes a set of ASP.NET server controls to use when building a basic site, which tend to be extremely flawed. The HTML generated by the server controls are generally impossible to style properly with CSS (for example, no classes/IDs on elements that you would like to style). Your only option is to use their poorly documented and buggy APIs, or attempt to use XSLT to transform the output of their server controls.An Ektron "min site" includes a 300MB Workarea folder, which makes compilation and deployments take a very long time.If you attempt to use multiple web servers with Ektron, you will find that their synchronization solution, eSync, barely works. It will successfully synchronize a MS SQL database instance, but we were never able to get Ektron to reliably synchronize files between web servers. This actually becomes extremely troublesome, because their search feature relies on .txt files dumped onto the filesystem of the web servers with the contents of every web page on your site. Because Ektron fails at synchronizing files, Ektron search fails on multiple servers too.I used this product from versions 7.66 to 8.01 SP1, which totaled about a year and a half. The team I was working on used it to build a number of public facing sites which are still running on Ektron today, unfortunately. We slowly became entrenched in this product due to deadlines and resistance to switch to a different CMS.This review attempts to sum up the miserable experience of using Ektron from a developer's perspective, a server administrator's perspective, and the actual end content editor's perspective.In order to cope with the endless number of bugs with the CMS, we ended up writing our own wrapper API over a basic Ektron site that used REST web services to retrieve content so we didn't have to deploy the actual Ektron codebase with our sites. This allowed us to fix many of the bugs (such as not expiring content properly) , but this kind of effort when we're already paying for a solution is ridiculous.

If you're looking for a .NET based CMS, do yourself a favor and go with an open source CMS. If your company is afraid of open source products, there are much better, less expensive proprietary .NET content management systems out there.