Thank you for the question!
The Tale of the CloudFormation is there to explain it a little - the CF code was built through years by many people that were more or less experienced with the CloudFormation and eventually it became really hard to maintain - unmaintained, not up to date, tons of drifts, etc...
Then there was an internal team built for taking care of all the infrastructure, with expertise in Terraform and inability to dive into existing CloudFormation stacks in any reasonable time.
Terraform has just some little inconveniences that the team is aware of and we decided it's easier for us to get rid of CloudFormation as it was easier to achieve than fixing all the stacks - especially when not being experts in them.
To make things more complicated, there were parts of the infrastructure in Terraform too - but in a similar state as CF stacks and we decided to not reanimate them but build new code from scratch on what we actually see in the infrastructure.
Adam Brodziak
SRE / DevOps exploring Kubernetes, Docker, Cloud, AWS.
I wonder why go with Terraform? You loose some traits CloudFormation gives you, e.g. rollbacks on failed deploy, no need to keep external state. Since CF was used I guess it was AWS-only, so Terraform's questionable universality does not matter. Then why?