Complete post migration tasks
When migration completes, an email gets sent to the organization owner and at this point, anyone with access can sign in to the newly migrated Azure DevOps Services organization. But, before you make the organization available to all users, you should complete the common tasks listed within this article.
Spot check
Immediately after the organization becomes available, take a small team and do spot checks on the organization. We recommend that this team consists of the project collection administrators. This check shouldn't be in-depth, but rather making sure that major pieces from your collection were brought over.
- Source code: Verify that your source code repositories migrated correctly.
- Build history: Ensure your build history made it over.
- Area paths: Confirm that all area paths are still present.
These quick checks help you catch any missing or incomplete data before opening the organization to your entire user base.
Rename organization (optional)
In the Get started phase, you might have already created organizations with the final Azure DevOps Services organization names that you want to use. If this is your final migration, you can rename your newly migrated Azure DevOps Services organization to that desired name. For more information, see Rename your organization.
Set up billing
To pay for users or services in Azure DevOps, like hosted build and deployment agents, you need to set up billing for your organization. If you migrate more than one collection, you should ensure all your organizations are set up for billing with the same Azure subscription, and that your subscription is enabled for multi-organization billing. You can then assign as many Basic users as you need free of charge during the calendar month in which you run the migration.
Configure build agents
If you used automated build or deployment servers in your Azure DevOps Server environment, you can connect them to your Azure DevOps Services organization. As part of the migration, all your build definitions got migrated, but you must reconfigure agents and pools against your new Azure DevOps Services organization.
For more information, see Azure Pipelines agents.
If you plan to use your existing on-premises private build agents, you must clear their cache, which ensures that you don't encounter any build issues related to older Team Foundation Version Control (TFVC) or Git pointers to your on-premises collection. For more information, see refreshing caches on client computers.
Tip
If you used Release Management in Azure DevOps Server, then your release pipelines and history data migrated. But like with builds, you must reconfigure your agents(link again) and pools against the new organization.
Use Azure Artifacts
Azure Artifacts is included with Azure DevOps Services for all users granted a Basic license. There's no need to install an extension. Your Azure Artifacts data should be available post migration. For more information, see Azure Artifacts overview.
Customize Azure Boards
If you have an existing GitHub Enterprise Server connection associated with your Azure DevOps Server, it doesn't work as expected. Work items mentioned within GitHub might be delayed or never show up in Azure DevOps Services. This problem occurs because the callback URL associated with GitHub is no longer valid.
To resolve the problem, consider the following tasks:
- Remove and re-create the connection: Remove and re-create the connection to the GitHub Enterprise Server repository. Follow the sequence of steps provided in Connect from Azure Boards documentation.
- Fix the webhook URL: Go to GitHub's repository settings page and edit the webhook URL to point to the migrated Azure DevOps Services organization URL:
https://dev.azure.com/{OrganizationName}/_apis/work/events?api-version=5.2-preview.
For more information, see Configure and customize Azure Boards.
Review permissions
Your organization includes five free users with Basic access. For more information, see Add organization users and manage access.
Notify your teams
After your builds are running and license subscription is configured, we recommend that you open the organization to all users for validation. Then individual users can ensure that all the content is in place, has the right access level, and they can pull code.
Users of TFVC with local workspaces must remap their workspaces against the new organization, and Git users must reconfigure their remotes to pull code.
If anything is missing from the migrated organization, contact Support.