Upgrade path for STNO v2.0.0 to v3.0.x will orphan transit gateway and global network from stack

[t04glovern]

What were you initially searching for in the docs? We're in the process of trying to work out how we're going to migrate from STNO v2.0.0 to STNO v3.0.x and run into a problem whereas the documentation lists the following:

Deploy the v3 template along side v2 template and delete v2 template later.

This has the implication that the new stack will simply reference the transit gateway and global network by their ID's but no longer manage them as resources as part of a stack

Is this related to an existing part of the documentation? Please share a link https://docs.aws.amazon.com/solutions/latest/serverless-transit-network-orchestrator/update-the-stack.html

Describe how we could make it clearer Could the documentation be improved to make the fact that resources will be orphaned clear, and could they be improved to include steps to re-integrate the orphaned resources back into the hub stack?

Also is there any way that the v3.0.x stack can be deployed over the top of the v2.0.0 stack instead? We leveraged the following lab to do our deployments: https://controltower.aws-management.tools/automation/cfct/#setup-central-networking-using-serverless-transit-network-orchestrator-stno-advanced-lab. Which means our stacks are deployed with stacksets, so doing a side by side is not easy and means we're looking like we're going to be stuck on 2.0.0 indefinitely.

Misc Additionally, for users stuck on previous versions (prior to v3.0.0) could security patches be released (in a version 2.0.1 for example) for changes made in v3.0.1 (https://github.com/aws-solutions/serverless-transit-network-orchestrator/releases/tag/v3.0.1) so that we have a path forward