Expand my Community achievements bar.

SOLVED

CMS migration to AEM

Avatar

Level 1

Hello, 

I am trying to find out information relevant to a proposed migration of existing website content from Silverstripe to AEM, a certain amount of new content creation would be fine, but it would be easier if would just export and reimport the majority of our current content from one to the other. Is there any currently existing documentation that would give an overview to the best practice for this?

Please let me know if I can provide any more relevant details to help with an answer

Cheers!

Ben

1 Accepted Solution

Avatar

Correct answer by
Level 8

There are several available APIs/approaches to getting content into the AEM repository. Some of the available documentation is:

Generally there are some analysis tasks you need to complete in order to effectively migrate your content in an automated way:

  1. You need to complete your Template and Component design. In order to understand how to migrate your content you need to have completed you template and component design so you understand you target content model. You should keep the fact that you want to do automated migration in mind when doing your template and component design so that you don't create a content model that can not be mapped to your existing model (so for example if you current content model has a single rich text editor field for the body of you page, and you create a template/component design that requires splitting that content into two columns it will be difficult to automatically migrate the content). Don't lock your self into automatically migrating however. If you just do a one to one mapping you may lose the ability leverage much of the capability and flexibility that AEM provides you. 
  2. Once you complete you template and component design you need to map your existing content model to your new template and component design to understand which templates and components you will be migrating content into. 
  3. This process will help determine what content can realistically be automatically migrated. 

Conceptually there are a couple of viable automated approaches that will work

  • Use the package manager to import content as XML. This works well in your system supports exporting as XML. A few steps are required to leverage this approach:
    • Enter some example content into your target templates and components and then create a package with this content and export it. Packages are just zip files in a specific format with what is essentially a manifest telling the package manager what to import, and a a set of XML files in a specific format holding the content. This will be your target format. 
    • Design a process to transform your current system's XML into the CQ package format. This involves not just mapping to specific XML elements, but also creating the right directory structure and filter/configuration files to ensure that the content is properly import. 
    • This works well if the XML output you have is already page focused and the mapping is relatively easy. 
  • Create a scripting process that accesses the content on your current system and uses the Sling POST servlet to store the content. This works well if your current system does not have a good export mechanism and you need to do a lot of API calls to your current system to get content. 
  • Write Java code in an OSGI bundle that accesses your current system directly, or accesses a export format and then uses the AEM/Sling/JCR Java APIs to store content in the appropriate locations in AEM. 
  • Finally there are some commercial products out there for content migration that will assist in this, however those require significant investment and consulting and so may not be cost effective for small amounts of content. 

View solution in original post

3 Replies

Avatar

Employee Advisor

Ben,

I don't know Silverstripe, so I cannot really tell you if it makes sense to import data or to re-enter it all together. Some things which proved to be important when you plan to migrate content:

  • Content structure: In JCR you need to have a tree, where your pages live. Many other CMSes don't have a tree and also no "natural hierarchy", but just a flat set of pages, which are connected to the navigation; and by this navigation they get a kind of hierarchy. CQ requires you to think about your hierarchy. Because not having though about makes it quite hard (coding, managing, access control, ...).
  • In CQ you normally build your pages out of small number of templates, and then you have the choice to use components as you like. You are quite flexibel here and you should stay flexible.
  • Thought of access control?

Especially if you migrate off an older system, you might have problems with these aspects, and in many times it proved to be much better to just copy&paste the old content to CQ.

Jörg

Avatar

Correct answer by
Level 8

There are several available APIs/approaches to getting content into the AEM repository. Some of the available documentation is:

Generally there are some analysis tasks you need to complete in order to effectively migrate your content in an automated way:

  1. You need to complete your Template and Component design. In order to understand how to migrate your content you need to have completed you template and component design so you understand you target content model. You should keep the fact that you want to do automated migration in mind when doing your template and component design so that you don't create a content model that can not be mapped to your existing model (so for example if you current content model has a single rich text editor field for the body of you page, and you create a template/component design that requires splitting that content into two columns it will be difficult to automatically migrate the content). Don't lock your self into automatically migrating however. If you just do a one to one mapping you may lose the ability leverage much of the capability and flexibility that AEM provides you. 
  2. Once you complete you template and component design you need to map your existing content model to your new template and component design to understand which templates and components you will be migrating content into. 
  3. This process will help determine what content can realistically be automatically migrated. 

Conceptually there are a couple of viable automated approaches that will work

  • Use the package manager to import content as XML. This works well in your system supports exporting as XML. A few steps are required to leverage this approach:
    • Enter some example content into your target templates and components and then create a package with this content and export it. Packages are just zip files in a specific format with what is essentially a manifest telling the package manager what to import, and a a set of XML files in a specific format holding the content. This will be your target format. 
    • Design a process to transform your current system's XML into the CQ package format. This involves not just mapping to specific XML elements, but also creating the right directory structure and filter/configuration files to ensure that the content is properly import. 
    • This works well if the XML output you have is already page focused and the mapping is relatively easy. 
  • Create a scripting process that accesses the content on your current system and uses the Sling POST servlet to store the content. This works well if your current system does not have a good export mechanism and you need to do a lot of API calls to your current system to get content. 
  • Write Java code in an OSGI bundle that accesses your current system directly, or accesses a export format and then uses the AEM/Sling/JCR Java APIs to store content in the appropriate locations in AEM. 
  • Finally there are some commercial products out there for content migration that will assist in this, however those require significant investment and consulting and so may not be cost effective for small amounts of content. 

Avatar

Level 1

Thanks orotas - lots of food for thought there! It seems like we can probably manage to balance an amount of manual content copy and paste for the main, more heavily dynamic pages, while automating the majority of the simpler, more static pages on the site. And yes, very important for us to plan this in the right order if we're not going to have a total meltdown! We'll definitely be prioritizing the template design now. I'll have some discussion with the Dev team and hopefully we'll be able to come to a viable strategy from this

Thanks again for your help!