Migration to AEM as a Cloud Service | Community
Skip to main content
AEM_Forum
AEM_Forum
Level 10
November 6, 2023
Solved

Migration to AEM as a Cloud Service

  • November 6, 2023
  • 1 reply
  • 1425 views

Hi all,

 

As per Adobe, there are four phases for this and the third is Go-Live | Adobe Experience Manager.

I am not able to comprehend the activities in this phase,

 

To me, the Migration involves. 1. Code Migration, 2. Content/Data Migration.  

Two steps are described in this URL are: Initial Production Migration and Incremental Top-Ups. What are we migrating in these? Code or Content?

 

1. How and when is code migrated? 

2. Are we distinguishing between data and content?

3. If so, How and when is each of these is migrated?

 

Appreciate all your replies.

 

Thanks,

Rama.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MarkusBullaAdobe

The four phases you are referring to are:

  1. Readiness Phase
  2. Implementation Phase
  3. Go Live
  4. Post Go Live

Your specific query is about the third phase: Go Live.

Looking at your specific questions:

 

@aem_forum  schrieb:

Two steps are described in this URL: Initial Production Migration and Incremental Top-Ups. What are we migrating in these? Code or Content?

Both migration types - initial and top-up migrations - are about content, not code.The difference of the two is about the migration methodology, not the coverage of what is being migrated. Simply speaking, initial migration is a full migration starting on a wiped repository while the top-up migration only covers diffs to the last migration run.

 

@aem_forum  schrieb:

1. How and when is code migrated?

Source code (aka your application) needs to be refactored and updated to comply with AEM CS standards during the implementation phase. The "How" is covered by #1 in my initial post. The updated code will be pushed to Cloud Manager and Cloud Manager Pipelines will built the application and bake it into an AEM CS image.

 

@aem_forum  schrieb:

2. Are we distinguishing between data and content?

No. In the context of AEM I don't see a differentiation between data and content. The most important differentiation here is between code and content. The key differentiator here is if it is part of a mutable (= content) or immutable path (= code) of the repository. (Please note: oftentimes both is being referred to as "content" because also your code will be stored on the content repository. A claim of AEM and it's predecessor CQ was that "Everything is content" which is somewhat changing with Cloud Services.) Also, I'm unable to find a reference to the migration of "data" in the documentation you linked so I'm unsure where this differentiation in your question comes from.

 

@aem_forum  schrieb:

3. If so, How and when is each of these is migrated?

Your actual migration of production content will be part of the Go Live phase.

That being said, you will be running both, initial and top-up migrations, during your implementation phase already to gather data and experience as well as identify potential issues that you want to avoid during the actual go-live migration in this third phase.

I touched on the difference between both migration methods/steps in my initial response as well as my answer above to your question #1.

 

Hope this helps!

 

1 reply

MarkusBullaAdobe
Adobe Employee
MarkusBullaAdobeAdobe Employee
Adobe Employee
November 6, 2023

Hi @aem_forum!

When migrating to AEM Cloud Services, there are different topics to look at:

 

1. Refactoring your application

You will need to evaluate your existing application running in AEM to make sure that it is compatible with AEM as a Cloud Service. This documentation gives you a high level overview on what's different with AEM CS. The AEM CS Development Guidelines give you a more detailed view on the most important changes from an implementation point of view. The Best Practices Analyzer will support you to identify required changes to your application. It will highlight known patterns, code, etc. that are not compliant to AEM CS guidelines.

The effort and time required for the refactoring and modernization of your code base highly depends on the current state and size of your code base. Most parts can already be done on an existing AEM 6.5 environment and don't necessarily need an AEM CS setup. So you can start this process immediately as a preparation for your move.

In rare cases, you might need to find new solution designs for certain requirements as older approaches might no longer be possible with AEM CS. Obviously, these tasks might require a bit more planning, design and implementation effort.

Once your application is ready and running in AEM CS, you are ready to go.

 

2. Content migration to Cloud Services

To migrate your existing content to AEM CS, there is the Content Transfer Tool available. For large and/or complex content hierarchy, I recommend to start first evaluations of the tool early and run multiple test migrations to identify potential issues that might occur (e. g. due to corrupted/invalid content on the source repository, etc.) and address them early on. The CTT has different options for migration to meet varying customer needs. Regarding your question on Initial vs. Top-up migrations: Initial migrations most probably refers to a wipe-migration that will delete everything from the target repository before transferring content from the source to the target. This process is faster that a top-up migration where only changed content is migrated. For common projects you will run a single initial (wipe) migration, then validate the state and application on AEM CS. As your business will be running and content author will still be working on the source system, you will run one (or multiple) shorter top-up migration during a content freeze before executing the actual s witch to AEM CS.

 

Personally, I would not make a distinction between data and content here. The only relevant distinction is between code from step 1 (deployed as content package) and content migrated through CTT as step 2.

 

Both steps can run in parallel or sequentially, depending on your timeline, team setup and other factors.

 

 

In addition, the recommendations for AEM upgrades from earlier versions still hold true, also for migrations to AEM CS. Citing from an older thread on an upgrade to AEM 6.5:


  • Migrating the existing platform - basically updating the dependencies (primarily: the AEM uber jar) and getting your existing application and website running on the new product version.
  • Source code modernization - projects that have been developed for older versions of AEM usually have quite some "legacy" code that does not reflect the latest development best practices and recommended patterns. Refactoring your existing code base to modernize it should be on your list.
  • Adapting new features - newer versions of AEM come with additional features that you may want to leverage, such as editable templates, content and experience fragments and many more. You may want to check the "What's new" section of the release notes for the latest versions of AEM.

 

Hope this helps!

    AEM_Forum
    AEM_ForumAuthor
    Level 10
    November 7, 2023

    Thanks Markus. This is really an elaborate description of the point I raised.

    But my queries are specifically on the Adobe documentation.

    As per me I should be following Adobe documentation.

     

    As per Adobe, there are four phases for migration to ACS and the third is Go-Live | Adobe Experience Manager.

    Please try to address my queries in my post.

     

    I will take your stand that there is no separation between data and content.

     

    Thanks,

    Rama.

    MarkusBullaAdobe
    Adobe Employee
    MarkusBullaAdobeAdobe EmployeeAccepted solution
    Adobe Employee
    November 7, 2023

    The four phases you are referring to are:

    1. Readiness Phase
    2. Implementation Phase
    3. Go Live
    4. Post Go Live

    Your specific query is about the third phase: Go Live.

    Looking at your specific questions:

     

    @aem_forum  schrieb:

    Two steps are described in this URL: Initial Production Migration and Incremental Top-Ups. What are we migrating in these? Code or Content?

    Both migration types - initial and top-up migrations - are about content, not code.The difference of the two is about the migration methodology, not the coverage of what is being migrated. Simply speaking, initial migration is a full migration starting on a wiped repository while the top-up migration only covers diffs to the last migration run.

     

    @aem_forum  schrieb:

    1. How and when is code migrated?

    Source code (aka your application) needs to be refactored and updated to comply with AEM CS standards during the implementation phase. The "How" is covered by #1 in my initial post. The updated code will be pushed to Cloud Manager and Cloud Manager Pipelines will built the application and bake it into an AEM CS image.

     

    @aem_forum  schrieb:

    2. Are we distinguishing between data and content?

    No. In the context of AEM I don't see a differentiation between data and content. The most important differentiation here is between code and content. The key differentiator here is if it is part of a mutable (= content) or immutable path (= code) of the repository. (Please note: oftentimes both is being referred to as "content" because also your code will be stored on the content repository. A claim of AEM and it's predecessor CQ was that "Everything is content" which is somewhat changing with Cloud Services.) Also, I'm unable to find a reference to the migration of "data" in the documentation you linked so I'm unsure where this differentiation in your question comes from.

     

    @aem_forum  schrieb:

    3. If so, How and when is each of these is migrated?

    Your actual migration of production content will be part of the Go Live phase.

    That being said, you will be running both, initial and top-up migrations, during your implementation phase already to gather data and experience as well as identify potential issues that you want to avoid during the actual go-live migration in this third phase.

    I touched on the difference between both migration methods/steps in my initial response as well as my answer above to your question #1.

     

    Hope this helps!

     

      Terms & ConditionsAccessibility statement

      Loading footer...