Separate creation from operation
The repository contains the platform's original provisioning reference and the scripts used for specific migrations. Its current documentation marks the live CloudFormation definition as frozen. Routine submissions validate source and tests; they do not create, update, or delete cloud resources.
This is a useful architectural boundary. Application development continues without turning every release into an infrastructure change. The original network, certificate, storage, and instance configuration remains available for review without being presented as a command to rerun on a live system.
Make migration intent inspectable
The recorded activation workflow assembled committed source, checked the expected remote revisions, and packaged a controller artifact. Individual migration scripts were constrained to a named purpose, such as hostname configuration or a sender change. Their documentation records completion so a one-time exception does not silently become an ongoing maintenance pathway.
Configuration keeps public identifiers separate from secrets. OAuth client credentials and repository access credentials belong to controlled runtime configuration; source records the structure of the integration.
Keep plans separate from mutations
The preserved source makes dependency ordering and configuration validation reviewable. Historical provisioning examples remain documentation of creation, while current releases use the service broker and exact-revision receipts. This separation reduces ambiguity about whether a change edits application behavior, adjusts runtime configuration, or changes the infrastructure itself.