I remember when a colleague didn’t want to use TF from an unknown company in his saas. His company is now gone but terraform is alive and widely used.
For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had we started using TF now, we wouldn't have had this problem. But of course, nobody's at fault here.
[1] https://github.com/hashicorp/terraform/blob/v0.13/CHANGELOG....
In particular (AFAIK), there are no tools for moving stuff around, so in addition to the TF restructuring, one also need to write scripts to manually move the resources.
Or if it's a big mess you can 'rm' and 'import'.
I'm not even sure that the new resource address can be figured out, and the list of resources can be search/replaced in order to produce a single renaming (mv'ing) script.
Even if this was possible, it would likely require:
- either each module to be moved monolithically, which is risky (e.g. data sources may break, since there's no referential integrity) and requires a fully designed and implemented destination module (carrying two different representations of the resources contained in each module).
- or, and I don't know if this works in real world, creating an structured but empty destination module, and slowly moving resources from the leaves down to the root. this is a lot of work, and probably requires a very large amount of references to be carried cross-modules.
Big refactorings are a difficult in any language/framework, but in TF are particularly so, because referencing between resources is rigid, so it's hard to move small parts and their references. Doing this is Chef is much simpler, since resource name and address matches and it's under control of the developer (but Chef has a different approach, of course).