Resolved I have a few questions

@wechat_os_Qy0zxXr3tUn91KHH3TiEQAyf8

1. Host migration is not currently an integrated feature supported for NGO, and continuing a game session would require all clients to drop their current connection to the host (i.e. in relay) and then establish a new connection. So, as you pointed out this is not an option if your project requires this type of functionality. However, you can have the host store off game state for a network session that the remaining clients could use to start up a new game session where one of the clients (up to your implementation... the system with the best RTT and capabilities or the like) starts as the host, loads the persisted state (your choice of how that is persistently stored), and then sends some form of "new session" state to the lobby (where the remaining clients are still connected to and waiting for this) which then the remaining clients just invoke NetworkManager.StartClient().
   There is a lot of "in between the lines" code involved in this approach, but it can be theoretically done...I just don't personally have a working example (at this time) that I could provide to you.
   You might look at the Mongo DB Realm SDK
   There is a good video about Managing player & world states in multiplayer games worth watching too.
   The pro for this: is that it reduces the cost for a dedicated game server per session.
   The con(s) for this: it can take a considerable amount of additional code and testing to implement and will still have the cost of persisting each game session's state (albeit possibly less expensive than 1 DGS instance per session).
2. There have been continued improvements to the DGS (dedicated game server) which should allow you to reduce the over-all size/processing consumption per game session. Since NGO is based on the UnityEngine itself, having multiple "sessions/rooms" per DGS instance can be accomplished... but would possibly end up yielding the same over-all processing cost (or possibly more depending upon implementation) as just having 1 session per DGS instance and if you are going to try this then I would definitely recommend looking into the 1st option before attempting this as really the DGS per session instance cost should be weighed against the additional development time/cost (if that is a factor for you). The DGS route requires some additional consideration to improve optimizations and there will be more optimization options in future updates that will even further help you to reduce the over-all size and processing consumption per instance.
   The pro for DGS (per session): less development time and faster turn around in regards to optimizations.
   The con for DGS: could be more expensive per session than the more development time intensive 1st approach. (I don't know what kind of game you are developing so it is hard to gauge how much information would be required to "store a full game session's state".)

Picking what is best really boils down to what is most important to your project and your budget (time and/or $$) as well as how often you think a host will drop its connection/game session completely and if that is a big enough concern for your project's goals/needs.