Follow the steps below to ingest your migration set from the Content Transfer Tool:
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.
The following notes apply to ingesting content:
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.
Ingestions do not support a Rapid Development Environment (RDE) destination. They will not appear as a possible destination choice, even if the user has access to it.
The following important notices apply to ingesting content:
You will be able to initiate 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.
Click on (i) button in the row to get more information about the ingestion job. You can see the duration of each step of the Ingestion when it is executing or completed by clicking on … and then on View durations. The information from the extraction is also shown to realize what is being ingested.
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 initiate 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.
After an ingestion is requested, a message like the following may be presented to the user: “The migration service on the destination environment is currently unreachable. Please try again later or contact Adobe support.”
This indicates that the Cloud Acceleration Manager was unable to reach the target environment’s migration service to start the ingestion. This can happen for a number of reasons.
The “Migration token” field is shown because in a few cases retrieving that token is what is actually disallowed. By allowing it to be manually provided, it may allow the user to start the ingestion quickly, without any additional help. If the token is provided, and the message still appears, than retrieving the token was not the problem.
Release Orchestrator automatically keeps environments up to date by applying updates automatically. If the update is triggered 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 message. You may choose to continue anyway, accepting the risk, by checking the field and pressing the button again.
Release Orchestrator is now being deployed to Development environments, so pausing updates on those environments should be done as well.
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.