A Cloud Migration Your Ai Agents Cannot Drift Away From

No migration work starts before the assessment is in CogmemAi: the inventory of services, data stores, integrations, secrets, scheduled jobs and traffic, the dependency map, and the scope document.

Run cogmemai-mcp migrate assess and read the result before touching anything. A migration without an inventory is a discovery exercise with production traffic as the test harness.

The migration scope document (the project intent) is the contract: what moves, what stays, what must hold throughout, what is out of scope, and what done means for each phase.

Every change to it goes through set_intent with a reason, and every phase is reviewed against it. Work that is not in the scope is not migration work.

NEVER plan a big-bang cutover.

Workloads move one at a time, lowest risk first, each with its own phase gate, so a failure affects one system and the lesson improves the next move. A dependency that forces two workloads to move together is a finding to write down, not a reason to move everything.

NEVER change the application and the infrastructure in the same step.

Move first with the smallest change that runs; modernize (managed services, containers, new frameworks) as a separate project afterwards, with its own scope. Two kinds of change in one cutover means a failure cannot be attributed.

No phase starts without a written rollback that has been rehearsed: how traffic returns to the source, how data written on the target during the window is reconciled, how long it takes, and who decides.

A rollback that has never run is a hope.

Data is verified on the target before cutover with row counts per table, checksums or hashes per partition, and a sample of records compared field by field, with the results stored as a memory.

"The copy finished without errors" is not verification.

NEVER run a bulk sync with a delete flag without a dry run first and a backup of the destination.

Sync tools with --delete remove whatever is missing on the source side, and a wrong path or a swapped argument empties the target.

NEVER export secrets from the source secret store to a file, a spreadsheet or a chat to move them.

Secrets are reissued in the target's secret manager (new credentials, new keys), the application is pointed at them, and the old ones are revoked after cutover. A migration is the moment every credential gets rotated for free.

Data stays in the residency class it has today unless the scope document says otherwise with the privacy owner's sign-off.

A migration never moves personal, health, payment or customer data to a region, country or provider the contracts do not allow, even temporarily, even for a staging copy.

The same test suite runs on the target with the same results before the first percent of traffic moves, plus a smoke test of every integration (payments, email, webhooks, scheduled jobs, third-party APIs) from the target network with the target's identities.

Differences are findings to resolve, not notes.

Dashboards, logs, alerts and an on-call owner exist for the target before it takes traffic, with the source's baseline numbers (latency, error rate, throughput, cost) written down for comparison.

A target with no dashboard cannot be judged healthy, so it cannot be cut over.

Cutover is gradual (weighted DNS, a load balancer split or a feature flag) with DNS TTLs lowered at least a day ahead, a freeze on schema changes during the window, and a go or no-go call recorded with the numbers.

Raising a TTL back or lifting the freeze happens only after the phase gate passes.

During cutover the data has exactly one writer: either the source goes read-only for the final sync, or dual writes are in place with reconciliation.

NEVER let both sides accept writes without a reconciliation plan, because the divergence is silent and the fix is manual.

NEVER decommission, delete or wipe the source environment in the same change as the cutover.

The source stays read-only and backed up for at least thirty days after the phase gate passes, then is decommissioned as its own planned change with a named approver and a final backup verified restorable.

The source's monthly cost is written down before the move, a budget with alerts exists on the target before it takes traffic, and the first full month on the target is compared with the baseline and stored as a memory.

A migration that does not know what it saved or cost cannot be called finished.

Every phase ends with cogmemai-mcp migrate gate "<phase>": the work is reviewed against the scope document, and the phase passes only with coverage of at least 80 and no violations.

A gate that fails blocks the next phase; the fix is to do the work, not to lower the bar. Results are stored so the whole migration has a record.

NEVER use the AWS root user for daily work and never create access keys for it.

Root has hardware MFA, no keys, and is used only for the handful of tasks that require it, each one logged. Everything else goes through IAM Identity Center roles.

NEVER create long-lived IAM access keys for people or workloads.

People sign in through Identity Center with short sessions; workloads assume roles (instance profiles, IRSA, Lambda execution roles, OIDC from CI). A key that must exist is rotated on a schedule and scoped to one task.

Creating an IAM user needs a written reason; the default is a role.

The only standing users are break-glass accounts with hardware MFA, and those are reviewed quarterly.

NEVER attach AdministratorAccess, PowerUserAccess or a policy with Action "*" or Resource "*" to a user, role or group outside the break-glass role.

Permissions are scoped to the actions and resources the job needs, and permission boundaries cap what any role can grant.

NEVER open SSH, RDP or a database port to 0.0.0.0/0 or ::/0 in a security group.

Administrative access goes through Systems Manager Session Manager or a bastion behind SSO; databases are reachable only from the application's security group.

NEVER remove or weaken the S3 Block Public Access settings at the account or bucket level, and never write a bucket policy with Principal "*".

Public content is served through CloudFront with origin access control, not from a public bucket.

NEVER turn off EBS default encryption, and never create an RDS instance without encrypted storage.

Each data class has its own KMS key with a rotation schedule and a key policy that names who may decrypt.

NEVER make an RDS instance or cluster publicly accessible.

Databases live in private subnets and are reached through the application tier, a bastion behind SSO, or Session Manager port forwarding.

NEVER delete a production database without a final snapshot, and never remove deletion protection as part of the same change that deletes.

Removing protection is its own reviewed change; the deletion is a second one, after the snapshot is verified restorable.

Every tier-1 data store is in an AWS Backup plan with a cross-region copy and a quarterly restore test that is written down.

Deleting a backup vault, a recovery point or a snapshot is a reviewed change, never a cleanup task.

NEVER disable GuardDuty, Security Hub, Config or Inspector in any account.

They are organization-wide, delegated to the security account, and their findings have an owner. Turning one off to make a deploy pass is an incident.

NEVER detach or delete a service control policy, leave the organization, or move an account out of its organizational unit without the security owner's approval.

SCPs are the floor under every account: they deny disabling CloudTrail, creating root keys, leaving the org and using unapproved regions.

Resources are created only in the approved regions for their data class, enforced by an SCP, and nothing with personal or regulated data is replicated across regions without the privacy owner's sign-off.

Cross-region replication and read replicas are changes, not defaults.

Workloads run in private subnets with egress through NAT or VPC endpoints; subnets do not auto-assign public IPs, and the only public addresses belong to load balancers and NAT gateways.

Attaching a public IP to an instance is an exception with a reason.

NEVER expose an EKS API endpoint to 0.0.0.0/0.

The endpoint is private or restricted to the office and CI CIDRs, nodes are in private subnets, and pods get AWS permissions through IAM roles for service accounts, never through node instance profiles with broad rights.

NEVER store a secret as a plain String parameter, in an environment variable definition, in user data or in a task definition.

Secrets live in Secrets Manager or SSM SecureString, are referenced by ARN, and rotate on a schedule.

Every resource carries Owner, Environment, CostCenter and DataClass tags, enforced by a tag policy and Config rule.

Untagged resources are reported weekly and reaped after thirty days in non-production. A resource nobody owns is a cost and a risk at once.

Every account has an AWS Budget with alerts at 50, 80 and 100 percent, routed to a person, before its first production workload.

Cost anomaly detection is on. Deleting a budget is a reviewed change.

Every auto scaling group, Lambda concurrency setting and DynamoDB on-demand table has a ceiling that someone chose on purpose.

A runaway loop or a scraper should hit a limit and an alert, not the credit card. Raising a ceiling above a hundred instances is a reviewed change.

The organization trail covers every account and region, writes to a bucket in the security account with object lock and MFA delete, and is never the thing that gets turned off to save money.

Log file validation stays on.

NEVER assign Owner or User Access Administrator to a person, group or service principal; those roles live only on the break-glass accounts with Privileged Identity Management and approval.

Contributor at subscription scope needs the platform owner's sign-off; everything else is a scoped built-in or custom role on a resource group.

Workloads authenticate with managed identities or workload identity federation, never with a service principal secret or certificate pasted into configuration.

Creating or resetting a service principal credential needs a written reason and an expiry under ninety days.

NEVER create a network security group rule that allows SSH, RDP, SQL or any port from Internet, * or 0.0.0.0/0.

Administrative access goes through Azure Bastion or a jump host behind Entra sign-in; databases accept traffic only from the application subnet.

NEVER allow anonymous blob access on a storage account or set a container's public access to blob or container.

Public content is served through Front Door or a CDN with a private origin; everything else is reached with Entra identities or short-lived SAS tokens.

NEVER turn off HTTPS-only or lower the minimum TLS version below 1.2 on a storage account, and never disable infrastructure encryption on accounts holding regulated data.

Shared key access is off where Entra authorization works.

NEVER enable public network access on an Azure SQL server, database for PostgreSQL or MySQL flexible server, or add a firewall rule that spans the whole internet.

Databases are reached through private endpoints from the application virtual network.

NEVER delete or purge a Key Vault, disable its purge protection or soft delete, or put a secret anywhere other than Key Vault.

Apps read secrets through Key Vault references or managed identity; CI reads them at run time, never at build time into an image.

NEVER delete or exempt an Azure Policy assignment at the management group level to make a deploy pass.

Policy enforces allowed locations, required tags, no public IPs, no public storage and diagnostic settings on everything. A deploy that Policy blocks is a deploy that needs a different design or a documented exception from the platform owner.

Resources are created only in the locations Policy allows for their data class, and paired-region replication (geo-redundant storage, SQL geo-replication, Cosmos multi-region) for regulated data needs the privacy owner's sign-off.

Residency is decided once, in the scope document, not per deploy.

NEVER set Defender for Cloud to the free tier on a production subscription or remove diagnostic settings that ship activity and resource logs to the central Log Analytics workspace.

The workspace is in the security subscription with retention of at least one year.

NEVER remove a CanNotDelete or ReadOnly lock as part of the same change that deletes or modifies the locked resource, and never delete a production resource group.

Removing a lock is its own reviewed change with a rollback; the deletion follows after the backup is verified.

NEVER create or update an AKS cluster with RBAC disabled, local accounts enabled, or an API server open to 0.0.0.0/0.

Clusters are private or CIDR-restricted, use Entra integration with Azure RBAC, workload identity for pods, and Defender for Containers.

Every production VM, database and file share is protected by a Recovery Services or Backup vault with soft delete and a quarterly restore test that is written down.

Disabling protection with data deletion, or deleting a vault, is a reviewed change, never a cleanup.

Every subscription has a Cost Management budget with alerts at 50, 80 and 100 percent routed to a person, before its first production workload, and an anomaly alert.

Deleting a budget is a reviewed change.

Every resource group and resource carries Owner, Environment, CostCenter and DataClass tags, inherited where Policy allows and enforced by a deny policy where it does not.

Untagged resources are reported weekly and removed from non-production after thirty days.

Platform services (storage, SQL, Key Vault, Cosmos, Service Bus, container registry) are reached over private endpoints from the virtual network, with public network access disabled once the private endpoint works.

A service reachable from the internet is an exception with a reason and an expiry.

Every human sign-in to the portal, CLI or any administrative role requires phishing-resistant MFA through Conditional Access, and privileged roles are activated just in time through Privileged Identity Management with approval and a time limit.

Standing privileged assignments are reviewed monthly and removed.

Virtual machines are created without public IP addresses; inbound reaches them through a load balancer, Application Gateway or Bastion.

A VM that needs a public address is an exception with a reason, an NSG that allows only the needed port, and an expiry.

NEVER grant roles/owner or roles/editor on a project, folder or organization to a person, group or service account.

Those are break-glass roles. Everyone else gets predefined or custom roles scoped to the resources the job touches, granted to groups, with IAM Conditions and expiry where the role is sensitive.

NEVER bind allUsers or allAuthenticatedUsers to any resource.

Public web content goes through a load balancer with Cloud CDN or Cloud Armor in front of a private backend; a bucket, function or service with an allUsers binding is an exposure, not a convenience.

NEVER create a user-managed service account key.

Workloads on Google Cloud attach a service account; everything outside uses workload identity federation. The organization policy disabling key creation stays on, and any key that exists is rotated and tracked to retirement.

NEVER create a VPC firewall rule that allows SSH, RDP, a database port or all protocols from 0.0.0.0/0.

Administrative access goes through Identity-Aware Proxy TCP forwarding; databases accept traffic only from the application's service account or subnet.

NEVER make a bucket or object public with an ACL, and never turn off uniform bucket-level access.

Buckets use uniform access with IAM, public access prevention enforced, and retention or versioning where the data class requires it.

NEVER give a Cloud SQL instance a public IP or an authorized network of 0.0.0.0/0.

Instances use private IP on the shared VPC and are reached through the Cloud SQL Auth Proxy or private service connect with IAM database authentication.

NEVER turn off automated backups or point-in-time recovery on a production Cloud SQL instance, delete its backups, or remove deletion protection in the same change that deletes it.

Restores are tested quarterly and written down.

NEVER delete or reset an organization policy constraint to make a deploy pass.

The floor is: domain restricted sharing, service account key creation disabled, resource location restriction, external IP access restricted, public access prevention on storage, and uniform bucket access required. A blocked deploy needs a different design or a documented exception from the platform owner.

Resources are created only in the locations the organization policy allows for their data class; multi-region and dual-region storage, cross-region Cloud SQL replicas and multi-region Spanner or Firestore for regulated data need the privacy owner's sign-off.

Residency is decided in the scope document, not per deploy.

Admin Activity and Data Access audit logs are on for every service that holds data, aggregated through an organization sink to a log bucket in the security project with retention of at least one year and a lock.

Shortening retention under a year or deleting the bucket is an incident.

NEVER create or update a GKE cluster with public nodes, legacy authorization, unshielded nodes or a control plane open to 0.0.0.0/0.

Clusters are private, use Workload Identity for pods, Binary Authorization for images, and are reached through authorized networks or IAP.

NEVER delete a project or remove a lien from a production project as a cleanup task.

Deleting a project is a planned decommission with a backup, a thirty-day read-only period and a named approver; removing the lien is its own reviewed change.

Every billing account and every production project has a budget with alerts at 50, 80 and 100 percent routed to a person, before its first production workload.

Unlinking billing or deleting a budget is a reviewed change, because unlinking billing stops the workload.

NEVER put a secret into a Cloud Run, Cloud Functions or GKE environment variable, a startup script or a container image.

Secrets live in Secret Manager, are mounted or referenced by version, and rotate on a schedule. Destroying a secret version is a reviewed change.

Every project and resource carries owner, environment, cost-center and data-class labels, and billing export to BigQuery is on so cost per label is a query, not a guess.

Unlabeled resources are reported weekly and removed from non-production after thirty days.

Projects that hold regulated data sit inside a VPC Service Controls perimeter with Private Google Access, so data cannot be copied to a bucket or dataset outside the perimeter by any identity, including an over-privileged one.

Perimeter changes are reviewed by the security owner.

Compute instances are created without external IPs and with Shielded VM on; inbound traffic reaches them through a load balancer or IAP, and egress goes through Cloud NAT.

An instance that needs an external address is an exception with a reason and an expiry.