Phase 1: Pre-migration Preparation
This phase establishes what the existing PKI supports and what the new PKIaaS environment must provide. EC works with the customer's PKI, security, infrastructure, networking, and application teams to define the target architecture and a migration sequence based on business criticality and technical dependencies.
Key activities
- Complete the Client Intake Form and conduct architecture workshops. Confirm certificate use cases, expected volumes, CA hierarchy, algorithms, key sizes, validity periods, revocation requirements, and enrollment methods.
- Inventory the existing Root and Issuing CAs, certificates, templates, applications, devices, and certificate owners. Identify certificates installed in locations that may not appear in the CA database or certificate management platform.
- Review each existing template and determine whether it should be recreated, consolidated, changed, or retired. Map every template that remains in use to an approved PKIaaS template or certificate profile.
- Identify dependencies on the existing CA certificates, CDP/AIA locations, NTAuth publication, Group Policy, and application-specific trust stores. Record systems that use certificate pinning or require a coordinated change with an application owner.
- Identify the customer-side hosts required for the PKIaaS Enrollment Gateway, CEP, NDES, or other selected integrations. Confirm DNS, firewall, service account, and access prerequisites before scheduling deployment.
- Agree on pilot groups, certificate migration waves, validation criteria, change windows, escalation contacts, and rollback triggers. Record the planned treatment of certificates that cannot be migrated before cutover.
Phase outcome
At the end of this phase, the customer and EC share one agreed picture of where the PKI is today and where it needs to be. The target PKIaaS design is approved, covering the CA hierarchy, algorithms, key sizes, validity periods, revocation settings and enrollment methods. Every existing CA, certificate, template and dependency is recorded in an inventory with a named owner, so nothing is missed during the migration. The customer-side prerequisites for the gateway and the integrations are confirmed, and a migration plan sets out the waves, pilot groups, change windows, validation checks and rollback triggers. This plan is the reference for every later phase, so the remaining work can proceed without reopening design decisions.