SCM to SCM Migration Playbook
Introduction
Are you thinking about moving to a SCM system from your current version control system or do you want to step out of your legacy source control management tool? Well, you may be concerned about how tough the migration process will be, where to find the resources and who will step in to help on the blockers. The fact that switching between systems can require a significant amount of work, complexity, and a learning curve, causes DevSecOps teams to typically worry about migration. But we are here to tell you that it's quite easy to migrate to SCM systems using Opsera.
How to Use the SCM Migration Task in Opsera?
You can use Opsera’s dedicated task “SCM to SCM Migration” from the task creation UI. The task can be set up, by simply choosing the details for the source and target repositories from a form and then the task must be triggered for execution, in order to start the migration.
There are a variety of ways to migrate projects in the Git-centric environments.
What Data Can be Migrated?
Source Code
Commit History
Bitbucket Groups to Github Teams
Git custodian scan for the migrated repos
Teams (groups) in Bitbucket In case of performing a BitBucket to GitHub migration, all teams in Bitbucket will be automatically migrated into the desired GitHub account.
Pull Requests and Webhooks: The Pull Requests and Webhooks from BitBucket to GitHub repositories are migrated along with the data. The SCM to SCM Migration task supports migration of Pull Requests along with history, from BitBucket Server to GitHub enterprise cloud using the Git CLI Importer.
Migration of branch permissions: The branch permissions along with the pull request reviewers & team members involved in bypass pull requests. This is currently supported for BitBucket Server to GitHub Cloud migration type.
LFS Migration: The migrated Github repositories which have large files over 100mb are marked as LFS (Large File Storage) in the Migration Summary Report.
Supported Features
Dry Run for Repo Analysis
Users can now dry run custom secret scanning patterns at the repository level. Dry runs allow admins to review and hone their patterns before migrating the data. Using the analysis, you can check if your repo files are within the size limit before migrating the repos, so that the migration does not stop or fail due to repo limit issues.
For this, while creating the task enable the toggle "Dry Run for Repo Analysis", and enter the file size for which the repositories must be identified (Example: 400 MB). Once the task is executed, the “Status Check" row shows the status of the file analysis. Now to view the list of repos that have exceeded the file size limit, click the “Reports" row. The list of all the migrated repositories will be displayed along with the indication if the files have exceeded the size limit. The green tick indicates that the repos do not have max limit files and can be successfully migrated.
Execute script for pre and post-migration against each repository.
Configure a script to run every time a repository receives new commits through push during your SCM Migrations. Define a pre-migration and a post migration script depending on when exactly the script needs to be triggered.
Pre-migration script example:
curl --location --request PUT 'https://bitbucket.sampleorg1.com/rest/api/latest/projects/'"${sourceWorkspace}"'' --header 'Content-Type: application/json' --user ''"${sourceAccountUsername}"':'"${sourceAccountSecret}"'' --data '{"public":false}'
curl --location --request POST 'https://bitbucket.sampleorg1.com/rest/api/latest/projects/'"${sourceWorkspace}"'/permissions/PROJECT_WRITE/all?allow=false' --header 'Content-Type: application/json' --user ''"${sourceAccountUsername}"':'"${sourceAccountSecret}"''Post-migration script example:
curl --location --request PUT 'https://bitbucket.sampleorg1.com/rest/api/latest/projects/'"${sourceWorkspace}"'' --header 'Content-Type: application/json' --user ''"${sourceAccountUsername}"':'"${sourceAccountSecret}"'' --data '{"public":false}'
curl --location --request POST 'https://bitbucket.sampleorg1.com/rest/api/latest/projects/'"${sourceWorkspace}"'/permissions/PROJECT_WRITE/all?allow=false' --header 'Content-Type: application/json' --user ''"${sourceAccountUsername}"':'"${sourceAccountSecret}"''Activity Logs
You can view the Activity log records in real time to spot check the migration and ensure there are no major problems.
What can all be viewed using Activity Logs?
Overall status of execution
Console Log details of the execution
Report of the components migrated
Click the Reports row to view the summary of the records migrated. You can view the information about the records that were migrated, the Org Name, and the migration status (success or failure).
You can view in-depth reports on the execution as they plan and carry out a migration between SCM systems to have a better understanding. The downloadable report contains details about the migrated branches and repositories, pull requests, webhooks, and the migration status of each repository that was migrated. Click the Download Report button to start the download of the detailed report.
Step-by-Step Procedure for Task Creation
Prerequisites
Super Admin access to Github Cloud organization
Super Admin access to Bitbucket Server repos
Open your Opsera account and navigate to the Tasks menu. Click the Create New Task button and choose SDLC Tasks. Start filling out the details in the Configure Task Details form by choosing the following details:
Name: Enter a name.
Type: Choose the type as SCM to SCM Migration.
Access Control: Set control for access based on who must have access to the task.
Migration Type: Choose the migration type.
Dry Run for Repo Analysis: Enable the Dry Run Analysis toggle to perform a dry run to check max size files in the repo before migration.
Source SCM Type: Choose a SCM Type. The supported SCM types are GitHub, GitLab, Azure and BitBucket.
Source Git Tool ID: Choose the Git Tool ID.
Repository Mapping: Map repositories from multiple source workspaces by choosing the relevant Source Workspace, Source Repository, Target Organization and Target Repository.
Once created, click Run Task to start the execution. The complete execution details loaded in Opsera for users to view.
Last updated
Was this helpful?