This issue covers the migration process from OSSM 2.x (likely 2.5 or 2.6) to OSSM 3.0. This is different from minor release upgrades.

While we will aim to make this as painless as possible, we expect that there will be more work than a minor release upgrade. From customer conversations to date, things that are important for them include:

• Being able to migrate an application while maintaining application traffic (zero-down time from an end user perspective)
• Not having to create a new cluster... it should be possible to have both OSSM 2 and 3 on the same cluster simultaneously. This makes it easier to have traffic load balanced against services in both meshes during the migration.
• The possibility of an incremental migration, where not all workloads are moved over at the same time - thus, it should be possible that one or more OSSM 2 meshes lives alongside one or more OSSM 3 meshes (with appropriate scoping).

Consider that customers may be starting with:

1. A single OSSM 2 mesh in "multi-tenant" mode (likely the majority of users)
2. An OSSM 2 mesh in "cluster-wide" mode
3. Multiple OSSM 2 meshes in "multi-tenant" mode

For customers with #3, they will need to choose a first tenant mesh to migrate over, and then choose to consolidate meshes or setup a multi-control plane configuration (probably about 10% of customers) to accommodate multiple control planes of OSSM 3.

Related documentation epic: https://issues.redhat.com/browse/OSSM-6706

Filip note's - https://docs.google.com/document/d/1lS3YxzZ02-0zlKBPD4PURH0kNMLbfWdm77CB1W25-H0/edit#heading=h.ur3qdjnrr09z