Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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.
Validate migrated content
Immediately after the organization becomes available, verify the migrated content and configuration to ensure all critical components successfully migrated. Your project collection administrators should lead this process and cover all major areas of your collection. We recommend validating the following:
- Source code: Confirm that all repositories migrated correctly and are accessible.
- Build history: Verify that the complete build history is intact and matches expectations.
- Area paths: Ensure all area paths are present and correctly structured.
- Work items: Review a representative sample of work items to confirm data integrity and relationships.
- Permissions & security: Validate that user permissions, groups, and access controls are correctly configured. Depending on how users are set up in your Azure DevOps Server, they might not appear in the Users hub of your new organization until after they sign in for the first time. If any users are missing post-migration, have them sign in and then recheck their status.
- Service connections & pipelines: Check that service connections and pipeline configurations are functional.
- Dashboards & widgets: Confirm that dashboards render correctly and widgets display expected data.
This validation helps identify any missing, incomplete, or misconfigured data before opening the organization to your broader user base, ensuring a smooth transition and minimizing disruption.
Important
Don't remove or destroy your on-premises data or decommission systems until you confirm that all expected data and functionality exist in the migrated organization.
Rename organization (optional)
If you created a placeholder organization with your desired name during the Get started phase, you can now rename your migrated organization to replace it. This step is only necessary if this is your final migration and you want to use a specific organization 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.