Migrating a VIP project to your own infrastructure

VIP projects typically start out on Adobe’s SharePoint and GitHub. This is a great way to get started and go live quickly. However, eventually you should move your project(s) to your own infrastructure for full ownership and control.

A content move from Adobe’s SharePoint to yours is best combined with a code repository move from Adobe’s GitHub organization to yours. Follow the steps below for a side-by-side migration without downtime:

Code migration

If migrating your project code from Adobe’s GitHub

1. Create a new, empty GitHub repository in your GitHub organization. By default, the repository should be public for easier collaboration.
2. Configure the AEM Code Sync GitHub App. for your new repository.
3. Copy all files and folders from the repository in Adobe’s GitHub organization to your new one.
4. Commit and push the code into the main branch.
5. A copy of your site is now available at https://main--project--customer.hlx.page
6. Compare with https://main--project--hlxsites.hlx.page to make sure everything works as expected.

If your project code is already in your own GitHub

In this case, create a temporary fork to enable side-by-side migration:

1. Create a fork of the code repository in your GitHub organization.
2. Configure the AEM Code Sync GitHub App. for your forked repository.
3. A copy of your site is now available at https://main--project-fork--customer.hlx.page
4. Compare with https://main--project--customer.hlx.page to make sure everything works as expected.

Content migration

Note: Skip this step if you are already using your own SharePoint or Google Drive.

1. Prepare your content root folder:
   1. SharePoint: Follow this documentation to set up your own SharePoint site, link it to your GitHub repository and register your own SharePoint user.
   2. Google Drive: create a new folder and share it with helix@adobe.com as Editor
2. Copy all content from Adobe’s SharePoint site to your own. An easy way to do this is using the OneDrive desktop app.: sync both sites to your local disk, copy the content over and wait until the upload has finished. Don’t forget to copy the .helix folder.
3. Share your root folder
4. Bulk-preview all content using the Admin API. Don’t forget to include the .helix folder in the paths array.
5. Verify the previewed content on https://main--project--customer.hlx.page
6. Bulk-publish the content using the Admin API. You can use the existing site’s sitemap.xml as a reliable source of published URLs.
7. Verify the published content on https://main--project--customer.hlx.live

Sidekick setup

Code and content migration

Authors will need to add the new project to their sidekick:

• Prepare a sharing URL with an “Add project” button for them using the sidekick configurator.
• Alternatively, authors can also navigate to the project’s new SharePoint URL or https://main--project--customer.hlx.page and then click “Add project” in the extension’s context menu or the “+” button in the tool bar..
• You can optionally prepare a second sharing URL with the old configuration to give your authors an easy way to remove the old project from their sidekick.

Content migration only

Authors will need to update the existing project configuration in their sidekick:

• Prepare a sharing URL for them using the sidekick configurator. Instruct authors to first click the “Remove project”button, followed by a click on the “Add project” button.
• Alternatively, authors can also select “Options” in the extenstion’s context menu, click “Edit” button on the project, manually enter the new SharePoint URL (same as the mountpoint URL in your fstab.yaml) and click the “Save” button.

Go-live

You migrated your project code from Adobe’s GitHub

To go live, switch the backend for your production domain in your CDN to the new origin https://main--project--customer.hlx.live.

• See the launch documentation for instructions on how to do this with various CDNs.

Your project code was already in your own GitHub

1. Change the fstab.yaml in your original repository to point to the same mount point URL as in your temporary fork.
2. Commit and push the change into the main branch.
3. Delete the temporary fork.