[sausagefeet]

The high-level vision of Stategraph is that the entire world's infrastructure should be representable as a single root module, with proper isolate and RBAC. It should scale and be secure. With that, the way Stategraph works best is everything being in a single repo and in a single root module.

Additionally, Stategraph should Just Work with your existing TF codebase. You important the state and you're off to the races.

Once all of your state is in Stategraph, though, moving state around really becomes a question of what name those piece of state should have. So, if you want to merge two root modules, it could be the case that you can check "do my resource names overlap?" If no, you can tell Stategraph to merge the states and then copy your code into a single root module and go. Otherwise, you need to do some resource renaming.

While we don't have all the details in place, I think it is quite likely that Stategraph will support metadata on your resources, perhaps with a new block. This way you could provide namespaces to collections of resources, and that could make merging even easier. But, there is a bit to figure out before that is a reality or determined to be the best way to go.

[solatic]

Yeah I get the feeling that the correct approach is something like defining (1) a naming convention for the One True State, (2) defining some kind of namespace, passed in the backend config, to which state identifiers are copied when their state IDs don't conform with One True State, (3) some kind of UI to propose/communicate + CLI to rewrite the state identifiers and add moved blocks to import code to start to use One True State.