Skip to content

Migration Planning Guide

This guide helps you plan an organization-wide migration from classical cryptography to post-quantum cryptography (PQC). Whether you're transitioning from RSA to ML-KEM or upgrading from PKCS#7 to JOSE, proper planning ensures smooth migration with minimal disruption.

Migration Strategy Overview

Why Migrate to PQC?

Quantum Threat Timeline: - 2030s: Large-scale quantum computers estimated (NIST, NSA projections) - Store-Now-Decrypt-Later: Adversaries capturing encrypted data today for future decryption - Regulatory Deadlines: NSA CNSA 2.0 mandates PQC by 2030-2035 for National Security Systems

Business Drivers: - ✅ Compliance: Meet regulatory requirements (FedRAMP, NIST, CNSA 2.0) - ✅ Risk Mitigation: Protect long-lived data (healthcare records, financial transactions, government documents) - ✅ Competitive Advantage: Demonstrate quantum-readiness to customers - ✅ Future-Proofing: Avoid costly emergency migration when quantum threat becomes imminent

Migration Approaches

Strategy: Migrate incrementally by data criticality and risk

Timeline: 12-24 months

Phases:

Phase 1 (Months 1-3): High-Risk Data - Migrate long-lived sensitive data (healthcare PHI, financial records, government secrets) - Use ML-KEM-1024 (highest quantum resistance) - Pilot with small dataset (10-20% of total data)

Phase 2 (Months 4-9): Medium-Risk Data - Migrate business-critical data (customer PII, contracts, intellectual property) - Use ML-KEM-768 (balanced security-performance) - Scale to 50-70% of data

Phase 3 (Months 10-18): Low-Risk Data - Migrate transient data (session tokens, temporary files) - Use ML-KEM-512 or maintain classical encryption (lower priority) - Complete migration to 90%+

Phase 4 (Months 19-24): Decommissioning - Retire classical encryption systems - Full PQC deployment - Continuous monitoring and optimization

Benefits: - ✅ Lower risk (pilot validation before full rollout) - ✅ Incremental investment (spread costs over time) - ✅ Learning curve (team gains experience with PQC) - ✅ Rollback capability (revert if issues discovered)

Drawbacks: - ⏱️ Longer timeline (12-24 months) - 🔧 Dual-algorithm support (maintain both classical and PQC during transition)

Approach 2: Big-Bang Migration

Strategy: Migrate all data in a single cutover event

Timeline: 3-6 months (planning), 1 weekend (execution)

Phases:

Phase 1 (Months 1-2): Planning & Assessment - Inventory all encrypted data - Identify dependencies (applications, systems, integrations) - Design migration architecture

Phase 2 (Months 3-4): Testing - Test PQC algorithms in staging environment - Performance benchmarking (validate throughput) - Integration testing (SDK, CLI, API)

Phase 3 (Months 5-6): Migration Preparation - Build migration scripts (batch re-encryption) - Prepare rollback procedures - Schedule cutover window

Phase 4 (Weekend): Execution - Friday 6 PM: Begin maintenance window - Friday 6-12 PM: Re-encrypt all data (RSA → ML-KEM) - Saturday 12-6 AM: Deploy updated applications (SDK updates) - Saturday 6 AM: Verify migration success - Saturday 12 PM: Resume normal operations

Benefits: - ⚡ Fast migration (weeks vs months) - 🔧 No dual-algorithm support (simplifies architecture) - ✅ Complete quantum readiness immediately

Drawbacks: - ⚠️ Higher risk (all-or-nothing) - ⏱️ Downtime required (maintenance window) - 💰 Higher upfront cost (large batch operation)

Approach 3: Hybrid (Parallel Operation)

Strategy: Run classical and PQC encryption in parallel, transition gradually

Timeline: 6-12 months

How it Works: - Encrypt new data: Use PQC algorithms (ML-KEM, ML-DSA) - Maintain old data: Keep RSA-encrypted data as-is (decrypt on demand) - Gradual re-encryption: Re-encrypt old data opportunistically (when accessed)

Benefits: - ✅ Zero downtime (no maintenance window) - ✅ Low risk (gradual transition, rollback anytime) - ✅ Pay-as-you-go (migrate high-value data first)

Drawbacks: - 🔧 Complex (dual-algorithm support required) - ⏱️ Extended timeline (months to full migration) - 📊 Monitoring required (track migration progress)

Migration Timeline Template

Example: 12-Month Gradual Migration

Month Milestone Activities Success Criteria
1-2 Planning Inventory data, assess risk, design architecture Migration plan approved
3 Pilot Migrate 10% high-risk data, test in staging Pilot successful, no data loss
4-6 Phase 1 Migrate 40% data (high-risk + medium-risk) <0.1% error rate
7-9 Phase 2 Migrate 40% data (low-risk) 80% total data migrated
10-11 Phase 3 Migrate remaining 10%, performance tuning 100% data migrated
12 Decommission Retire classical encryption, full PQC deployment Classical algorithms disabled

Migration Checklist

Phase 0: Assessment (Before Migration)

  • [ ] Data Inventory: Catalog all encrypted data (location, format, algorithm, volume)
  • [ ] Risk Assessment: Classify data by sensitivity (high/medium/low risk)
  • [ ] Dependency Mapping: Identify applications using encrypted data
  • [ ] Performance Baseline: Measure current encryption/decryption throughput
  • [ ] Compliance Requirements: Determine applicable regulations (HIPAA, PCI-DSS, FedRAMP)

Phase 1: Planning

  • [ ] Select Approach: Choose gradual, big-bang, or hybrid
  • [ ] Choose Algorithms: Select PQC algorithms (ML-KEM-768 recommended)
  • [ ] Design Architecture: Plan key management, integration points
  • [ ] Build Timeline: Create month-by-month migration schedule
  • [ ] Budget: Estimate costs (AnkaSecure licensing, professional services, downtime)

Phase 2: Testing

  • [ ] Staging Environment: Deploy AnkaSecure in test environment
  • [ ] Generate PQC Keys: Test key generation (ML-KEM, ML-DSA)
  • [ ] Test Re-encryption: Migrate sample data (RSA → ML-KEM)
  • [ ] Performance Testing: Validate throughput meets requirements
  • [ ] Integration Testing: Test SDK/CLI/API with your applications
  • [ ] Rollback Testing: Verify rollback procedures work

Phase 3: Migration

  • [ ] Backup: Back up all encrypted data (before migration)
  • [ ] Execute Migration: Run re-encryption scripts (batch or gradual)
  • [ ] Validate: Verify data decrypts correctly with new keys
  • [ ] Monitor: Track error rates, performance metrics
  • [ ] Update Applications: Deploy SDK updates (if needed)

Phase 4: Post-Migration

  • [ ] Verify: Confirm 100% data migrated successfully
  • [ ] Decommission: Retire classical encryption keys (after grace period)
  • [ ] Document: Update documentation (architecture diagrams, runbooks)
  • [ ] Train: Educate team on PQC operations
  • [ ] Monitor: Continuous monitoring (key rotation, algorithm updates)

Risk Mitigation

Risk: Data Loss During Migration

Mitigation: - ✅ Backup before migration: Full backup of all encrypted data - ✅ Test with sample: Pilot with 1-10% of data first - ✅ Verify after migration: Decrypt sample data to confirm integrity - ✅ Rollback plan: Keep RSA keys active during grace period (30-90 days)

Risk: Performance Degradation

Mitigation: - ✅ Performance testing: Benchmark PQC algorithms in staging - ✅ Choose right algorithm: Use ML-KEM-768 for balance (not ML-KEM-1024 if performance critical) - ✅ Horizontal scaling: Add more instances if throughput drops

Risk: Application Compatibility Issues

Mitigation: - ✅ SDK updates: Update to latest SDK version (supports PQC) - ✅ Integration testing: Test all applications in staging - ✅ Gradual rollout: Deploy to dev → staging → production

Risk: Compliance Gaps

Mitigation: - ✅ Regulatory mapping: Verify PQC algorithms meet your regulations - ✅ Audit trail: Document migration for compliance audits - ✅ Legal review: Consult legal team on compliance impact

Cost Estimation

Direct Costs

AnkaSecure Licensing: - SaaS: Usage-based pricing (operations/month) - On-Premise: Contact sales@ankatech.co for enterprise licensing

Example (1 million operations/month): - Re-encryption operations: 1,000,000 × $0.001 = $1,000/month - Key generation: 100 keys × $1 = $100/month - Total: ~$1,100/month (SaaS model)

Professional Services (On-Premise): - Installation and configuration: Contact sales@ankatech.co - Architecture consulting: Contact sales@ankatech.co - Migration support: Contact sales@ankatech.co

Indirect Costs

Internal Resources: - Engineering team (plan, develop, test, deploy) - DevOps team (infrastructure, monitoring) - Security team (risk assessment, compliance validation)

Downtime (if applicable): - Maintenance window (big-bang approach) - Lost revenue during migration

Training: - Team training on PQC concepts - Developer training on SDK/API updates

Best Practices

1. Start with High-Risk Data

Prioritize data that: - Has long retention period (>10 years) - Is highly sensitive (PHI, PII, state secrets) - Is subject to strict regulations (HIPAA, FedRAMP)

Example: Healthcare organization migrates patient records first, then administrative data later.

2. Use Hybrid Cryptography During Transition

Combine classical + PQC for defense-in-depth:

// Hybrid encryption (RSA + ML-KEM)
EncryptRequest request = EncryptRequest.builder()
    .keyId("rsa-key")  // Classical encryption
    .plaintext(data)
    .build();

EncryptResponse rsaEncrypted = client.encrypt(request);

// Second layer: ML-KEM encryption
EncryptRequest pqcRequest = EncryptRequest.builder()
    .keyId("ml-kem-key")  // PQC encryption
    .plaintext(rsaEncrypted.getCiphertext())  // Encrypt the ciphertext
    .build();

EncryptResponse doubleEncrypted = client.encrypt(pqcRequest);
// Result: Adversary must break BOTH RSA and ML-KEM

Benefits: - 🛡️ Protected against classical AND quantum attacks - 🔄 Gradual transition (maintain compatibility)

3. Automate Migration

Use CLI scripts for batch processing:

#!/bin/bash
# migrate-to-pqc.sh

# Read list of RSA-encrypted files
while read file; do
  echo "Migrating $file..."

  # Re-encrypt: RSA → ML-KEM
  ankasecure-cli crypto reencrypt \
    --input "$file" \
    --output "${file}.mlkem" \
    --new-key ml-kem-production-key

  # Verify migration
  ankasecure-cli crypto decrypt \
    --input "${file}.mlkem" \
    --output /dev/null  # Just verify, don't save

  if [ $? -eq 0 ]; then
    echo "✓ $file migrated successfully"
  else
    echo "✗ $file migration failed" >> migration-errors.log
  fi
done < encrypted-files.txt

echo "Migration complete. Check migration-errors.log for failures."

4. Monitor Migration Progress

Track Metrics: - Migration Rate: Files/day, GB/day - Error Rate: Failed re-encryptions (target: <0.1%) - Performance: Throughput (MB/s), latency (ms) - Completion: % of data migrated

Dashboard Example (Grafana, Datadog): 

Migration Progress: 65% (650,000 / 1,000,000 files)
Error Rate: 0.03% (300 failures)
Throughput: 1.2 GB/hour
ETA: 14 days

5. Maintain Rollback Capability

Keep classical keys active during grace period:

  • Grace Period: 30-90 days after migration
  • Why: Allows rollback if issues discovered
  • When to Delete: After verifying 100% data migrated correctly

Rollback Procedure: 

# If issues found, revert to RSA encryption
for file in *.mlkem; do
  # Re-encrypt: ML-KEM → RSA (rollback)
  ankasecure-cli crypto reencrypt \
    --input "$file" \
    --output "${file%.mlkem}.rsa" \
    --new-key rsa-rollback-key
done

Migration Phases in Detail

Phase 1: Assessment & Inventory

Objectives: - Understand current cryptographic landscape - Identify migration scope and complexity - Estimate effort and timeline

Activities:

  1. Data Inventory:
  2. Run discovery scripts (find all encrypted files)
  3. Catalog encryption algorithms (RSA, AES, PKCS#7)

  4. Measure data volume (GB, file count)

  5. Application Inventory:

  6. Identify applications using encryption (list all services)
  7. Determine SDK/library versions (Java, Python, Node.js)

  8. Map encryption usage (where, how often, which algorithms)

  9. Risk Classification:

  10. High risk: Long-lived data (>10 years retention)
  11. Medium risk: Sensitive business data (5-10 years retention)
  12. Low risk: Transient data (<5 years retention)

Deliverables: - Data inventory spreadsheet (location, algorithm, volume, risk) - Application dependency map - Risk assessment report

Phase 2: Planning & Design

Objectives: - Select migration approach (gradual, big-bang, hybrid) - Design target architecture - Create detailed migration plan

Activities:

  1. Choose Migration Approach:
  2. Assess organization's risk tolerance
  3. Evaluate budget and timeline constraints

  4. Select gradual, big-bang, or hybrid approach

  5. Select PQC Algorithms:

  6. Encryption: ML-KEM-768 (recommended, Level III)
  7. Signatures: ML-DSA-65 (recommended, Level III)

  8. High security: ML-KEM-1024, ML-DSA-87 (Level V)

  9. Design Key Management:

  10. Key generation strategy (pre-generate vs on-demand)
  11. Key rotation policy (frequency, automation)

  12. HSM integration (if required for compliance)

  13. Create Timeline:

  14. Month-by-month migration schedule
  15. Milestones and success criteria
  16. Resource allocation (team size, budget)

Deliverables: - Migration architecture diagram - PQC algorithm selection document - Detailed project plan (Gantt chart, milestones)

Phase 3: Testing & Validation

Objectives: - Validate PQC algorithms meet requirements - Test migration procedures in staging - Identify and resolve issues before production

Activities:

  1. Staging Environment Setup:
  2. Deploy AnkaSecure in test environment
  3. Mirror production data (sample or synthetic)

  4. Configure monitoring (track performance, errors)

  5. Algorithm Testing:

  6. Generate PQC keys (ML-KEM-768, ML-DSA-65)
  7. Encrypt sample data
  8. Measure performance (throughput, latency)

  9. Validate against requirements

  10. Migration Testing:

  11. Re-encrypt sample data (RSA → ML-KEM)
  12. Verify decryption succeeds

  13. Test rollback procedures

  14. Integration Testing:

  15. Update SDK to latest version
  16. Test application integration (encrypt, decrypt, sign, verify)
  17. Load testing (simulate production workload)

Success Criteria: - ✅ All tests pass (0 critical failures) - ✅ Performance meets requirements (throughput, latency) - ✅ Rollback procedures validated

Deliverables: - Test results report - Performance benchmark report - Updated migration plan (based on test learnings)

Phase 4: Migration Execution

Objectives: - Migrate production data to PQC algorithms - Minimize disruption to business operations - Validate migration success

Activities:

  1. Pre-Migration Backup:
  2. Full backup of all encrypted data
  3. Backup verification (restore test)

  4. Store backup off-site (disaster recovery)

  5. Execute Migration:

  6. Gradual: Migrate 10-20% per week
  7. Big-Bang: Migrate 100% in maintenance window

  8. Hybrid: Encrypt new data with PQC, re-encrypt old data on access

  9. Validation:

  10. Decrypt sample data (verify integrity)
  11. Check error logs (monitor failure rate)

  12. Performance monitoring (verify throughput maintained)

  13. Application Updates:

  14. Deploy updated applications (SDK version, algorithm changes)
  15. Rolling deployment (avoid downtime)
  16. Verify integration (end-to-end testing)

Success Criteria: - ✅ 100% data migrated (or target percentage for gradual) - ✅ Error rate <0.1% - ✅ Performance maintained (or improved) - ✅ Applications functioning normally

Phase 5: Post-Migration & Decommissioning

Objectives: - Verify migration success - Retire classical encryption - Continuous improvement

Activities:

  1. Verification Period (30-90 days):
  2. Monitor for late-discovered issues
  3. Validate decryption success rate (100%)

  4. Gather team feedback

  5. Decommissioning:

  6. Disable classical encryption algorithms (RSA, ECDSA)
  7. Delete classical keys (after grace period)

  8. Update documentation (reflect PQC-only architecture)

  9. Continuous Improvement:

  10. Key rotation automation (schedule annual rotations)
  11. Performance optimization (tune based on metrics)
  12. Team training (PQC best practices)

Tools & Automation

Migration Scripts

AnkaSecure CLI provides migration commands:

# Batch re-encryption
ankasecure-cli migration batch-reencrypt \
  --input-dir /data/encrypted/ \
  --output-dir /data/pqc-encrypted/ \
  --source-algorithm RSA-2048 \
  --target-algorithm ML-KEM-768 \
  --target-key ml-kem-production-key

# Progress tracking
ankasecure-cli migration status

# Output:
# Migration Progress: 45% (450,000 / 1,000,000 files)
# Success Rate: 99.97% (300 failures)
# Throughput: 1.5 GB/hour
# ETA: 18 days

Monitoring & Alerting

Track Migration Metrics: - Progress: % of data migrated - Error Rate: Failed operations (target: <0.1%) - Performance: Throughput (MB/s), latency (ms) - Completion ETA: Estimated time to completion

Alerts: - ✅ High error rate (>1%) - ✅ Slow migration (below target throughput) - ✅ Storage capacity (approaching limit)

Common Pitfalls & Solutions

Pitfall 1: Underestimating Data Volume

Issue: Migration takes 3x longer than planned

Solution: - Conduct thorough inventory before planning - Add 30% buffer to timeline estimates - Consider parallel processing (multiple migration workers)

Pitfall 2: Neglecting Application Updates

Issue: Applications break after migration (expect RSA, receive ML-KEM)

Solution: - Update SDK/libraries before migration - Test application compatibility in staging - Gradual rollout (canary deployment)

Pitfall 3: Insufficient Testing

Issue: Production issues discovered after migration

Solution: - Test migration procedures thoroughly in staging - Validate rollback procedures (actually test them) - Pilot with non-critical data first

Pitfall 4: Poor Communication

Issue: Stakeholders surprised by downtime or compatibility issues

Solution: - Communicate migration plan to all stakeholders - Provide regular status updates - Set expectations (timeline, potential issues)

Next Steps

Ready to Migrate? Start with:

  1. RSA → ML-KEM Migration - Technical walkthrough
  2. RSA → ML-DSA Migration - Signature migration
  3. PKCS#7 → JOSE Conversion - Format migration
  4. Algorithm Selection Guide - Choose right PQC algorithms

Need Assistance? - Professional Services: services@ankatech.co - Architecture Consulting: solutions@ankatech.co - Support: support@ankatech.co

Documentation Version: 3.0.0 Last Updated: 2025-12-26