A cloud migration changes almost everything about how infrastructure is deployed and managed. It introduces new networking topologies, new load balancing, new DNS configurations, and often new approaches to certificate management — AWS Certificate Manager, Azure Key Vault, cloud-native ACME integration. Each of these changes has certificate implications. Managing them well requires treating certificates as a first-class concern in migration planning, not an afterthought.
What changes during migration — and why it matters for certificates
IP addresses and hostnames change. Services moving to cloud infrastructure get new IP addresses. Load balancers change. In some cases, fully qualified domain names change — internal services that previously had hostnames on private DNS may get new names. Each of these changes has certificate implications: the new endpoint needs a valid certificate, and the old endpoint may still be running during a transition period.
Certificate management tooling changes. On-premises certificate management often involves a mix of CA portal processes, manual file management, and custom scripts. Cloud environments typically offer managed certificate services — AWS Certificate Manager, Azure Key Vault with certificate support, GCP Certificate Manager. These services have different renewal models, different API interfaces, and different limitations. Migrating from one approach to another is itself a certificate migration.
The ownership model may change. In traditional on-premises environments, a central IT team often manages all certificates. In cloud environments, individual application teams may use cloud-native certificate services for their own deployments. This decentralisation can improve agility but complicates visibility — certificates that were previously in a central inventory may scatter across dozens of cloud accounts and services.
New certificate requirements emerge. Cloud environments often introduce new TLS communication paths that did not exist on-premises: inter-service mTLS in a service mesh, load balancer to backend TLS, private CA for internal Kubernetes services. These require certificates that may not be contemplated in the existing certificate management process.
The dual-environment period
Most migrations run both environments in parallel for a period — the old environment handling traffic while the new environment is validated, with a cutover once confidence is established. This dual-environment period creates specific certificate risks:
Certificates expiring in the old environment during transition. If the migration runs longer than anticipated and certificates in the old environment expire during the transition period, the old environment stops working before the migration is complete. This is particularly dangerous when the old environment is still handling production traffic while the new environment is being validated.
Certificates issued for new endpoints not covering old endpoints. New certificates issued for the cloud environment may cover new hostnames but not old ones. During the transition, traffic may still be reaching old hostnames that need their own current certificates.
Certificate inventory divergence. During the transition period, the certificate inventory needs to reflect both environments. If monitoring only covers one — typically the original environment — the new environment's certificates are unmonitored and may expire without triggering alerts.
Certificate planning for migrations
The practical approach is to treat the certificate migration as an explicit work stream alongside the infrastructure migration, not as something handled implicitly. This means:
Before migration begins:
- Inventory all certificates in the existing environment — not just the ones you know about, but everything, including certificates on services being migrated that may not be in the current tracking system.
- Check expiry dates for all certificates against the expected migration timeline. Any certificate expiring during the migration window needs to be renewed before the migration or have a specific renewal plan as part of the migration plan.
- Document the certificate management approach for the target environment — which managed services will be used, how renewal is handled, who is responsible.
During migration:
- Add new environment endpoints to certificate monitoring as they are created — do not wait until the migration is complete.
- Verify certificate coverage for each service before cutover — check that the correct certificate is in place, that the chain is valid, and that TLS configuration meets requirements.
- Maintain monitoring of the old environment until it is fully decommissioned. Certificates in the old environment are still production certificates while it handles traffic.
After migration:
- Remove old environment endpoints from the monitored inventory once decommissioned — do not leave stale endpoints generating false alerts.
- Clean up DNS. Remove CNAME records and A records pointing to decommissioned infrastructure. Dangling DNS after a migration is a common source of subdomain takeover vulnerabilities.
- Verify that the new environment's certificate management approach — whether managed service or ACME automation — is working correctly and is covered by monitoring.
Private CAs and internal certificates in cloud environments
Cloud migrations often surface internal certificate complexity that was previously hidden. On-premises services communicating over private networks may not have used TLS at all — the network was considered trusted. In cloud environments, the shared responsibility model and zero-trust security principles push toward encrypting all internal communication, including service-to-service traffic.
This creates a need for internal certificate infrastructure that may not have existed before. Cloud providers offer managed private CA services (AWS Private CA, Azure Private CA) that can handle this, but they need to be planned, configured, and integrated with the services that need internal certificates. This is another reason to treat certificates as an explicit migration work stream rather than something to figure out on the fly.
How CertControl supports migrations
CertControl's ability to add and monitor endpoints in both old and new environments simultaneously makes it well-suited for the dual-environment migration period. As new services come online in the cloud environment, they can be added to monitoring immediately — giving the same coverage to the new environment that the existing environment already has.
The CT log enumeration used by the external scanner automatically discovers new subdomains as they get certificates — so new cloud services that obtain publicly trusted certificates show up in the certificate inventory within minutes of issuance, without requiring manual inventory updates during an already-complex migration process.
Post-migration, the platform supports the cleanup phase — identifying old endpoints that are no longer active, flagging certificates that have been removed from active use but remain in the inventory, and confirming that the new environment's certificate coverage is complete before the old environment is decommissioned.