Java Migration Examples

Sample projects to migrate from other products to Azure serivces.

To build benchmark for Azure Migration Copilot, we need example projects for test.

For phase one, we cover four scenarios:

1. RabbitMQ Spring AMQP to Azure Service Bus
2. AWS S3 to Azure Blob Storage
3. AWS SQS to Azure Service Bus
4. Add managed identity configurations for SQL database.

Getting Started

1. Put the source projects on "main" branch.
2. After done the migration work, put the migrated projects on "expected" branch.

How to contribute

1. Find Suitable Open Source Projects

   • Look for Java projects that need migration
   • Ensure the project uses permissive licenses like MIT/BSD/Apache. Don't use projects with restrictive licenses like GPL.
   • The project can compile (in the long term, we will check the converted project can compile, too)
   • Recommended: The project contains only a few files that needs to be converted (say <10). We try to cover different scenarios in different projects, rather than covering all scenarios in a single project.

2. Submit Initial PR

   • Submit the original project via PR to the main branch. The PR title should be like [Import] Project Name.
   • Submit an identical copy to the expected branch. The PR title should be like [Import] Project Name.

3. Implement Migration

   • Implement migration code on the expected branch

4. Submit Migration PR

   • Submit the migrated code via PR to the expected branch
   • Include detailed description of migration changes and rationale in the PR

5. Review & Merge

   • Wait for at least 1 reviewer to review your PR

Manual Project Conversion Guidelines

1. Do semantic compatible conversion from A to B. Do not try to correct logic errors or do refactoring.
2. Keep the class and method names unchanged when possible, e.g., DON'T change class S3Config to class StorageConfig.
   • This is currently limited by the followed migration work, to allow to tool to correctly analyze and correlate the diff, and compare the results.
   • In the long term we may enhance to make it more friendly to best naming practice.
3. Tests (mostly integration tests) - skip for now, comment related tests out, and remove the imports.
   • integration tests may involve test framework dependencies and mocks, which are currently out of scope.
4. pom.xml - remove the source product dependencies when all the usages have been converted
5. application.{properties,yaml} - if we converted a code segment, and the original code uses some configurations in the Spring app configuration (or other configuration files), we should update the configuration accordingly.

How to Accomplish Common User Actions

If you have trouble doing something related to this repository, please keep in mind that the following actions require using GitHub inside Microsoft (GiM) tooling and not the normal GitHub visible user interface!

• Switching between EMU GitHub and normal GitHub without logging out and back in constantly
• Creating a repository
• Changing repository visibility
• Gaining repository permissions, access, and roles
• Enabling easy access to your low sensitivity and widely applicable repository by setting it to Internal Visibility and having any FTE who wants to see it join the 1ES Enterprise Visibility MyAccess Group
• Migrating repositories
• Setting branch protection
• Setting up GitHubActions
• and other actions

This README started as a template provided as part of the StartRight tool that is used to create new repositories safely. Feedback on the README template used in this repository is requested as an issue.