Follow the steps below to ingest your migration set from the Content Transfer Tool:
You can run the optional pre-copy step to significantly speed up the ingestion phase. The pre-copy step is most effective for the 1st full extraction and ingestion. Refer to Ingesting with AzCopy for more details.
Did you remember to log a support ticket for this ingestion? See Important Considerations Before Using Content Transfer Tool for that and other considerations to help make the ingestion successful.
Go to Cloud Acceleration Manager. Click on your project card and click on the Content Transfer card. Navigate to Ingestion Jobs and click on New Ingestion
Review the ingestion checklist and ensure that all the steps have been completed. These are necessary steps to ensure a successful ingestion. You will be able to proceed to the Next step only if the checklist has been completed.
Provide the required information to create a new ingestion.
If the source was Author, it is recommended to ingest it into the Author tier on the target. Similarly, if source was Publish, target should be Publish as well.
If the target tier is
Author, the author instance will be shutdown during the length of the ingestion and will be unavailable to users (for example, authors or anyone performing maintenance, etc.). This is to protect the system, and prevent any changes which could either be lost or cause an ingestion conflict. Please ensure that your team is aware of this fact. Also note that the environment will appear hibernated during the author ingestion.
You can run the optional pre-copy step to significantly speed up the ingestion phase. Refer to Ingesting with AzCopy for more details.
If ingesting with pre-copy is used (for S3 or Azure Data Store), it is recommended to run Author ingestion first alone. This will speed up the Publish ingestion when it is run later.
You will be able to kick-off an ingestion to the destination environment only if you belong to the local AEM administrators group on the destination Cloud Service author service. If you are unable to start an ingestion, refer to Unable to Start Ingestion for more details.
If the setting Wipe is enabled before ingestion, it deletes the entire existing repository and creates a new repository to ingest content into. This means that it resets all settings including permissions on the target Cloud Service instance. This is also true for an admin user added to the administrators group. You will need to be re-added to the administrators group in order to start an ingestion.
Click on Ingest
You can then monitor the Ingestion phase from the Ingestion Jobs list view and use the ingestion’s action menu to view the log as the ingestion progresses.
Once Ingestion is completed, click on (i) button on the top right corner of the screen to get more information about the ingestion job.
The Content Transfer Tool has a feature that supports differential content top-up where it is possible to transfer only changes made since the previous content transfer activity.
After the initial content transfer, it is recommended to do frequent differential content top-ups to shorten the content freeze period for the final differential content transfer before going live on Cloud Service. If you have used the pre-copy step for the 1st full ingestion, you can skip pre-copy for subsequent top-up ingestions (if the top-up migration set size is less than 200GB) because it may add time to the entire process.
Once the ingestion process is complete, to ingest the delta content you will need to run a Top-Up Extraction and then use the top-up ingestion method.
You can do this by creating a new Ingestion Job and ensure that Wipe is disabled during the Ingestion phase, as shown below:
The automatic retrieval of the migration token may fail for different reasons, including you setting up an IP allow list via Cloud Manager on the target Cloud Service environment. In such scenarios you will see the following dialog when you attempt to start an ingestion:
You will need to retrieve the migration token manually by clicking on the “Get token” link on the dialog. This will open another tab that displays the token. You can then copy the token and paste it into the Migration token input field. Now, you should be able to start the ingestion.
The token will be available to users who belong to the local AEM administrators group on the destination Cloud Service author service.
You will be able to kick-off an ingestion to the destination environment only if you belong to the local AEM administrators group on the destination Cloud Service author service. If you don’t belong to the AEM administrators group, you will see an error as shown below when you try to start an ingestion. You can either ask your administrator to add you to the local AEM administrators or ask for the token itself, which you can then paste into the Migration token input field.
Release Orchestrator automatically keeps environments up to date by applying updates automatically. If the update is triggerred when an ingestion is being performed, it can cause unpredictable results including the corruption of the environment. That is one of the reasons a support ticket should be logged before starting an ingestion (see “Note” above), so that temporarily disabling the Release Orchestrator can be scheduled.
If Release Orchestrator is still running when an ingestion is being started, the UI will present this error message. You may choose to continue anyway, accepting the risk, by checking the field and pressing the button again.
A common cause of a Top-up Ingestion failure is a conflict in node ids. To identify this error, download the ingestion log using the Cloud Acceleration Manager UI and look for an entry like the following:
java.lang.RuntimeException: org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0030: Uniqueness constraint violated property [jcr:uuid] having value a1a1a1a1-b2b2-c3c3-d4d4-e5e5e5e5e5e5: /some/path/jcr:content, /some/other/path/jcr:content
Each node in AEM must have a unique uuid. This error indicates that a node that is being ingested has the same uuid as one that already exists at a different path on the target instance.
This can happen if a node is moved on the source between an extraction and a subsequent Top-Up Extraction.
It can also happen if a node on the target is moved between an ingestion and a subsequent top-up ingestion.
This conflict must be resolved manually. Someone familiar with the content must decide which of the two nodes must be deleted, keeping in mind other content that references it. The solution may require that the top-up extraction is done again without the offending node.
Once you have completed Ingesting Content into Target, you can view logs of each step (extraction and ingestion) and look for errors. See Viewing Logs for a Migration Set to learn more.