It's not about the specific resources for the most part, it's about knowing what needs replacing and why things are where they are, all while keeping your migration under version control.
Also to be fair, with good enough module abstractions and generic enough problems you can completely replace their implementation with few changes to their call sites for things like:
- A module that fully sets up a static site with DNS, CDN on an S3-compatible service
- A module for setting up an OCI image repo, and spinning resources that runs an image from it as a daemon somewhere.
- A module for setting up an OCI image repo, and sets up a "cron" job to run a binary off of it.
Sure the migration is unlikely to be as clean as terra[grunt|form] down && terra[grunt|form] up but it can get close.
Also to be fair, with good enough module abstractions and generic enough problems you can completely replace their implementation with few changes to their call sites for things like:
- A module that fully sets up a static site with DNS, CDN on an S3-compatible service
- A module for setting up an OCI image repo, and spinning resources that runs an image from it as a daemon somewhere.
- A module for setting up an OCI image repo, and sets up a "cron" job to run a binary off of it.
Sure the migration is unlikely to be as clean as terra[grunt|form] down && terra[grunt|form] up but it can get close.