“There’s no way that company exists in a year.” ~ Tom Siebel, Founder of Siebel CRM Systems, speaking about Salesforce.com
We all know where Siebel is now vs Salesforce. And it is inevitable where the future of computing is. Moving to Adobe Managed Service (AMS) – which is a Cloud based service unlike traditional on-premise Adobe Experience Manager (AEM), makes a lot of sense. However it takes some care before moving in this direction. So here are the 7 common mistakes that are often made by enterprise organizations when moving to AMS, that you should avoid!
Not simplifying your DevOps lifecycle prior to AMS / Cloud Manager Upgrade
If you are like most on-premise Adobe Experience Cloud customer, you are likely using some form of Git repository – GitHub, BitBucket, etc., along with a customized Continuous Integration Systems such as Jenkins.
As your applications grow in both numbers and complexity there is often a need to create custom jobs and processes using these CI-CD tools. While some enhancements to your deployments are well thought of, there could always be add-ons, plugins and fast-forward approaches taken to perhaps, meet some deadlines. Well, this is the time to re-think your deployment processes – lack of which will result in some very expensive project failures.
When moving to Adobe Managed Services, not only do you host your AEM (and maybe Adobe Campaign) servers on the Cloud, but are you also required to migrate your CI-CD processes to Adobe’s CloudManager. As powerful as it is, CloudManager is built with pre-defined pipelines in mind. It is certainly possible to customize the various tasks within a CloudManager pipeline, but it does not necessarily provide the same flexibility as your on-premise Jenkins implementation.
So, one of the first few steps towards a successful AMS migration is to simplify your CI-CD Pipeline.
Not architecting around a multi-tenancy platform
It is not uncommon for a large organization to have multiple web properties and web applications within the same Adobe Experience Manager eco-system. Perhaps multiple web applications within AEM that are integrated to both up-stream (like retail POS, CRM) and down-stream systems (like Adobe Target). It is also not uncommon for each of these applications to be de-coupled systems with their own integrations, internal implementation architectures. Well, to gain efficiencies you need to consider moving to common platforms, services and authoring systems such as a common Component library.
Upgrading to AMS and taking advantage of the entire Adobe Experience Cloud eco-system that can track your customer journey end-to-end, requires consolidating siloed systems into a common platform. Sort-of like multiple tenants within an apartment complex. Just like a real estate apartment complex provides common rules and services within which tenants need to work – to reduce costs and gain efficiency, considering applications to be tenants within a platform provides the same advantages.
When upgrading to AMS, re-aligning to a multi-tenant architecture goes a long way in your organization’s ability to map your customer’s journey and take meaningful actions. Multi-tenancy is the mantra for being nimble and manage your customer journey.
Underestimating a Cloud Migration upgrade
I don’t think there is anyone out there who believes that migrating from on-premise to any type of Cloud service is a breeze. That said, AEM, Analytics, Demdex (Audience Manager) and Neolane (Campaign )applications have their own differences between their on-prem and cloud versions. For example, AEM on AMS cannot be an old version of AEM. As of this writing your web application on AEM needs to be compatible with AEM 6.4 SP2 before migrating to AEM on AMS.
Not utilizing best practices of a Cloud platform upgrade
As an organization if you are currently working with a solutions partner with prior experience with AMS, take their advice. If you haven’t, well, it makes sense to work with one who has. Working with an experienced partner with experience makes all the difference between success and failure!
For example –
- Choosing between AWS vs Azure for the underlying cloud platform
- Factor in the right tag management framework – Adobe Launch vs Adobe DTM
- Choosing between Adobe Campaign Standard vs Classic and integration model with AEM
- Should you get Adobe Assets or if you should use out of box Digital Asset Management system (DAM) of AEM
- What’s a better approach – Lift-and-shift or Re-platform?
- Is this upgrade an opportunity to also implement Adobe Audience Manager?
These are all important questions not to be neglected during a AMS migration.
Choosing an improper AMS Level of Service
Adobe Managed Services currently comes in two flavors
- Basic and
We have seen customers buy more than they need and thereby spending unnecessary dollars that could have been used in other marketing efforts. On the flip side, we have also seen customers who have not purchased the right level of service that satisfies their experience roadman. Depending on the maturity of your technical staff, complexity of your application, your roadmap, etc., it is imperative that the right level of service be chosen.
Not re-aligning resources for a Cloud Platform
Migrating to AMS is not just a shift in where your technology is hosted, but also a shift in what technology frameworks to use. A shift in technology or in process, needless to say, requires retraining of your resources.
For example –
- Upgrading AEM requires a different skillset than supporting an existing AEM application
- Customizing Jenkins as a Continuous Integration platform requires a different skillset than managing Adobe’s CloudManager
- Administering Google Tag Manager is quite different from managing Adobe Tag Manager or Adobe Launch
- Each Data Management Platform (DMP) Platform, including Adobe’s Audience Manager, has it’s own challenges and technical skill requirements
All these factors require a shift in your resource skill set – either by providing additional training or hiring new staff.
Neglecting to include AMS Support within your end-to-end support model
If you are like any mature organization, your application development staff is not the same as your support team. And support teams work across applications and teams. While your core Adobe related applications move to the Cloud and you have support from Adobe Managed Services, your support staff need to work with Adobe’s staff and processes to make sure you have meaningful support across your own application ecosystem. It is therefore necessary to re-align your processes and application support touch points between your various systems to ensure there is a continuous hand-off during troubleshooting.
And this is just the start. There is more to be aware of! Give us a shout to learn more…
Message Sent (go back)