Cloud migration is no longer a niche IT initiative; it is a core program of work that blends project management, risk management, architecture, security, cost governance, and change management. A well-managed migration can improve agility and reduce technical debt, while a poorly managed one can cause data loss, compliance failures, major downtime, and cost overruns. This guide focuses on how to plan, execute, and govern cloud migration projects using a project-management lens—consistent with how South African university IT modules assess applied knowledge, documentation quality, and decision trade-offs.

Section 1: Foundations of Cloud Migration Project Management (Unisa MNG0001 / COS 332)

Cloud migration projects behave like large, multidisciplinary projects, not like “moving servers.” You manage a transformation program: people must adapt, systems must be redesigned for cloud operating models, governance and security must be established, and cost must be continuously controlled.

What Cloud Migration Projects Actually Include

A cloud migration project usually bundles several streams of work, each with its own deliverables:

• Discovery and assessment
  • Application inventory, dependency mapping, data classification, current performance baselines.
• Target architecture design
  • Landing zone, network design, identity integration, storage patterns, logging/monitoring strategy.
• Migration factory / execution
  • Cutover planning, data transfer, rehosting/refactoring/rewriting decisions, validation.
• Security and compliance
  • Threat modeling, encryption strategy, key management, audit logging, access controls.
• Operations readiness
  • Monitoring, incident response runbooks, backup/restore validation, SRE/ITIL integration.
• Change management and training
  • Staff upskilling, access provisioning, process updates, stakeholder communications.
• Financial governance
  • FinOps: tagging strategy, cost allocation, budget alerts, optimization.
• Project governance
  • Status reporting, risk registers, decision logs, stage gates, acceptance criteria.

A common exam failure is treating this as purely technical. Typical exam questions in South Africa (e.g., in Unisa-style IT management papers such as MNG0001-type management foundations, and similar module assessments across universities like COS/CNS-structured curricula) reward candidates who can structure answers with: objectives, scope, stakeholders, deliverables, risks, and controls.

Migration Models and Their Project Implications

A useful way to answer migration questions is to match migration strategy to project constraints.

1) Rehosting (Lift-and-Shift)

• Minimal code changes; typically faster.
• Project implications:
  • You still need platform governance, identity, networking, and monitoring.
  • Technical debt may remain; optimization may be delayed.

2) Replatforming

• Small changes to use managed services (e.g., managed database, containers).
• Project implications:
  • Medium risk; more dependency on cloud service maturity.
  • Requires careful validation of performance and cost.

3) Refactoring / Re-architecting

• Significant redesign to achieve cloud-native benefits.
• Project implications:
  • Higher effort; longer timeline; stronger dependency on architecture skills.
  • Requires robust DevOps practices and automated testing.

4) Retiring and Republishing

• Retire unused apps, replace with SaaS, or repurpose.
• Project implications:
  • Requires business process mapping and vendor/legal checks.
  • Success depends heavily on stakeholder alignment.

In exams, students often list types but omit why decisions differ. A strong answer explicitly links the strategy to constraints such as downtime tolerance, compliance requirements, skill availability, and budget.

Understanding the “Landing Zone” as a Project Workstream

The landing zone is the secure, scalable baseline where workloads run. It includes identity integration, network segmentation, logging, access management, and baseline policies.

Key landing zone elements (conceptual, provider-agnostic):

• Identity and access
  • Integration with the organization’s identity provider.
  • Role-based access control (RBAC), least privilege policies.
• Network architecture
  • Segmentation (public/private), routing controls, egress rules.
• Security controls
  • Encryption standards, key management model, security posture policies.
• Logging and monitoring
  • Centralized logs, metrics, alerts, audit trails.
• Governance guardrails
  • Policy-as-code, resource tagging requirements, automated compliance checks.

A project that skips a landing zone often fails later due to:

• inconsistent security settings across environments,
• inability to audit activity,
• uncontrolled growth of resources and costs.

Stakeholders and Responsibilities: Who Owns What?

Cloud migration governance is a stakeholder exercise. Typical stakeholder categories:

• Business sponsors
  • Provide funding, approve scope and acceptance criteria.
• IT leadership
  • Own architecture direction, operational readiness, and staffing.
• Security team
  • Define controls, approve risk exceptions, validate compliance evidence.
• Enterprise architecture
  • Approves target architecture patterns and standards.
• Network team
  • Own connectivity, segmentation, firewall rules, DNS.
• Data owners / data governance
  • Approve data classification, retention, migration schedules.
• Application owners
  • Provide requirements, define validation tests, sign off cutovers.
• Project manager / program manager
  • Own plan, schedule, risk tracking, stakeholder communications.
• Cloud platform team / DevOps
  • Build landing zone, automation pipelines, migration factory.

A common exam-style scenario: “The business insists on a quick cutover, while security requires evidence-based approvals.” Good answers show you understand conflict resolution:

• define stage gates (e.g., security sign-off before cutover),
• escalate exceptions with risk acceptance,
• communicate trade-offs with timelines.

Baseline Project Artifacts You Should Be Able to Describe

To score well, you must know which documents exist and what they contain:

• Project charter
  • Objectives, scope boundaries, high-level deliverables, governance.
• Migration assessment report
  • Application portfolio, complexity ratings, dependencies, risks.
• Target architecture document
  • Landing zone, network, identity integration, data patterns.
• Migration wave plan
  • Which apps move when, dependencies, sequencing rationale.
• Cutover plan
  • Downtime windows, rollback strategy, validation steps.
• Testing and validation strategy
  • Performance testing, functional testing, data integrity checks.
• Risk register
  • Likelihood/impact scoring, mitigation actions, owners.
• Communication plan
  • Stakeholder updates, incident communications, change notices.
• Training and readiness checklist
  • Staff access, operational runbooks, escalation paths.
• Cost governance plan (FinOps)
  • Tagging, budgets, monitoring dashboards, chargeback/showback approach.

Exams frequently ask: “Describe how you would manage risks during migration.” The best responses anchor risk management to these artifacts: risk register entries, mitigation plans, and acceptance gates.

Key Metrics for Cloud Migration Progress

Cloud migration projects need measurable progress beyond “we moved machines.”

Common metrics:

• Portfolio coverage
  • % apps assessed, % apps ready, % apps migrated, % apps validated.
• Cutover success

  • successful cutovers vs. # rollbacks, time to recovery (TTR).

• Performance and availability
  • Latency, throughput, error rates; uptime/availability targets.
• Data integrity
  • Checksums, row counts, referential integrity verification.
• Security posture
  • % resources compliant with security policies; audit readiness.
• Cost control
  • % resources tagged; variance vs. budget; cost per workload.
• Operational readiness
  • % workloads with monitoring + alerting + runbooks + backup verified.

A strong exam response not only lists metrics but describes how they drive decisions (e.g., stop further waves until integrity test pass rate exceeds a threshold).

Section 2: Planning and Estimating Cloud Migration Projects (CUT / CIS / Unisa-Compatible Practice)

Planning cloud migration means translating technical uncertainty into structured project control. In South African university contexts (e.g., modules that cover project planning, scope, and scheduling—often aligned with project management outcomes and assessed via essays and case scenarios), the strongest candidates show:

1. a clear plan,
2. justified sequencing,
3. realistic estimates,
4. controls for change.

Defining Scope, Objectives, and Acceptance Criteria

Start with measurable objectives and boundaries.

Example objective set (exam-friendly)

• Migrate N critical applications by a target quarter.
• Achieve 0 critical data integrity failures during first three cutovers.
• Maintain service availability within agreed downtime window per application.
• Meet baseline security controls and audit requirements before production cutover.

Acceptance criteria (often asked in exams)

• Functional tests pass for agreed scenarios.
• Data migration checks:
  • row counts match,
  • referential integrity preserved,
  • no unexpected truncation.
• Performance acceptance:
  • latency within X% of baseline (or within defined SLOs),
  • throughput meets minimum threshold.
• Security evidence:
  • encryption enabled,
  • logging enabled,
  • access controls validated.

Exams reward specificity: “we test” is weaker than “we execute data integrity checks and performance validation against SLOs.”

Application Portfolio Assessment: How to Know What to Move First

A typical first step is building an application inventory and scoring applications by:

• Business criticality
  • Revenue impact, operational role, user base, regulatory impact.
• Complexity
  • Number of dependencies, custom code, data volume.
• Migration suitability
  • Fit for rehosting vs replatform vs refactor.
• Risks
  • Data sensitivity, poor documentation, vendor constraints.
• Effort estimate
  • Engineering hours, testing complexity, required automation.

A scoring approach (framework you can describe)

Create a matrix with categories such as:

• Complexity: Low / Medium / High
• Dependency depth: Low / Medium / High
• Data sensitivity: Public / Internal / Confidential / Regulated
• Downtime tolerance: Hours / Minutes / Near-zero

Then compute a migration readiness score and sort into waves.

A strong exam answer includes how you handle exceptions:

• “Regulated data apps require extra security review and longer validation.”
• “Applications with deep dependencies must be migrated after the dependency mapping is completed and tested.”

Dependency Mapping and Sequencing (The Part Many Students Skip)

In real projects, application dependencies cause hidden schedule risk.

Dependency types:

• Technical
  • shared databases, message queues, APIs, file storage.
• Operational
  • scheduled jobs that trigger app workflows.
• Network
  • firewall rules, DNS dependencies, routing.
• Identity
  • service accounts, OAuth flows, SSO claims mapping.
• Data
  • referential integrity constraints, ETL pipelines.

Sequencing logic:

1. Migrate foundational services first (identity, network primitives, shared platforms).
2. Move downstream apps after dependencies.
3. Use temporary integration patterns when direct cutover is risky.

In exams, a typical prompt might be: “Explain how you would plan waves and manage dependencies.” The best responses show a wave plan logic, not just a list.

Migration Waves and “Migration Factory” Concepts

A migration factory is a repeatable process with tooling and standardized steps to migrate workloads faster and with fewer errors.

Core components:

• Automated assessment and discovery
• Standard build templates
  • for VM images, containers, infrastructure patterns.
• Transfer mechanisms
  • data replication tools, incremental sync approach.
• Validation automation
  • scripted health checks, integration tests.
• Release management
  • controlled cutover approach with approvals and rollback.

Project planning must include:

• staffing plan for factory roles,
• capacity planning (how many migrations per week),
• quality gates (tests before promotion).

Estimation Methods: From Guessing to Defensible Planning

Cloud migration estimation needs two dimensions:

1. Effort estimation
   • engineering, testing, security, operations readiness.
2. Schedule estimation
   • sequencing, dependency constraints, change approvals.

Practical estimation breakdown

A defensible estimate breaks migration into phases per application:

• Discovery and design
• Infrastructure setup
• Data migration (initial load + incremental sync)
• Environment configuration
• Testing (functional + performance + security)
• Cutover + rollback readiness
• Post-cutover stabilization

Where the application portfolio differs, the estimate differs. For example:

• A rehosting VM might have:
  • smaller code work,
  • but still significant dependency and testing work.
• A database migration might have:
  • higher testing and data integrity verification effort.

Scheduling Approaches and Risk Buffering

Cloud migration schedules are vulnerable to:

• data transfer variability,
• security approvals delays,
• vendor lead times,
• developer availability for testing windows.

Exam-strong scheduling approaches:

• Use time-boxed waves with explicit exit criteria.
• Include risk buffers on cutover windows, not just on the overall project.
• Plan security and compliance reviews as scheduled stage gates.

Change Control During Migration (How to Prevent Scope Creep)

Scope creep is common when stakeholders realize benefits mid-project.

Typical drivers of change:

• additional compliance requirements discovered midstream,
• new apps added to “must migrate” list,
• requirement changes for network segmentation,
• performance expectations raised after early demos.

A good change control process includes:

1. A change request with impact analysis (cost, schedule, risk).
2. Approval by a defined governance group.
3. Update to migration plan and re-baseline if needed.
4. Communication to impacted teams.

In exam scenarios, you can score by stating that:

• changes should not be allowed “informally” outside the stage gate,
• each wave must have a “freeze” date for acceptance tests and cutover planning.

Building a Cost Baseline (FinOps-Aware Planning)

Cloud migration must be planned for cost, or “optimizing later” becomes impossible.

Key cost planning elements:

• expected resource utilization (CPU, memory, storage, network egress)
• managed service pricing components
• reserved capacity vs on-demand (where applicable)
• logging/monitoring costs
• data transfer costs (ingress/egress patterns)

A common exam question: “Why do costs often exceed estimates?”
Strong answers include:

• missing tagging and allocation,
• baseline resources sized for performance without optimization,
• data egress surprises,
• uncontrolled development environments,
• lack of budgets and alerts.

Quality Gates: How You Ensure Each Wave Is Safe

Quality gates can include:

• Readiness gate
  • landing zone policies applied, identities configured, monitoring enabled.
• Pre-cutover gate
  • data integrity check scripts ready, rollback plan verified.
• Cutover gate
  • controlled change window, stakeholder confirmation.
• Post-cutover gate
  • performance and functional regression tests pass within thresholds.

Quality gates should be tied to measurable evidence.

Section 3: Executing Cloud Migration: Delivery, Testing, Cutover, and Operational Readiness (South African University Exam Focus)

Execution is where migration projects either succeed or become expensive failures. Good delivery is repeatable, evidence-driven, and disciplined about cutover and rollback.

The Migration Lifecycle: A Repeatable Execution Pattern

A common execution lifecycle across providers and architectures:

1. Build
   • configure target infrastructure according to landing zone standards.
2. Prepare
   • install/configure applications and dependencies.
3. Migrate
   • move data and deploy application versions.
4. Validate
   • run tests for functional correctness and data integrity.
5. Cut over
   • switch traffic and finalize environment.
6. Stabilize
   • monitor closely, fix issues, complete operational handover.

Exam candidates should name deliverables per stage:

• build outputs (infrastructure readiness evidence),
• migration outputs (replication completion proof),
• validation outputs (test reports, integrity check results),
• cutover outputs (change record, stakeholder sign-off).

Testing Strategies That Reflect Cloud Realities

Cloud migrations have different failure modes:

• latency and network throughput changes,
• differences in managed service behavior,
• identity/authorization issues after integration,
• asynchronous data synchronization problems.

Test types (and what they prove)

• Functional tests
  • application workflows behave as expected.
• Data integrity tests
  • row count checks, checksum comparisons, referential integrity validation.
• Security tests
  • access control correctness, least privilege enforcement, audit logging verification.
• Performance tests
  • load testing and performance regression; verifying SLOs.
• Failover/resilience tests
  • backup restore test, basic disaster recovery drills where feasible.
• Integration tests
  • API calls, messaging, scheduled jobs, cross-application workflows.

A key exam move: explain how you decide what to test. You select based on:

• risk rating (critical apps require more evidence),
• data sensitivity (regulated data needs stricter integrity proof),
• business downtime tolerance.

Data Migration: The Most Common Source of “Silent” Failures

Silent failures might not show up immediately but appear later as missing records or inconsistent relationships.

Data migration techniques

• Initial bulk load + incremental sync
  • reduces downtime.
• Offline export/import
  • simpler but often requires longer downtime.
• Streaming replication
  • complex but can minimize cutover downtime.

Integrity verification examples (how to describe in exams)

• Verify total record counts match expected values.
• Validate checksums for exported tables/files.
• Run application-level reconciliation:
  • compare key business transactions totals (where possible).
• Validate referential integrity:
  • ensure foreign key relationships remain consistent.

In exam answers, it helps to mention that you verify both data and behavior:

• the data might import correctly but the application may query differently due to schema or query changes.

Cutover Planning: Downtime Windows and Rollback Readiness

Cutover is a controlled release with high visibility.

A robust cutover plan includes:

• cutover window
  • exact start/end time, timezone, and target downtime.
• traffic switch strategy
  • DNS cutover, load balancer switch, routing changes.
• dependency handling
  • how dependent systems are switched in the correct order.
• pre-cutover checklist
  • backups verified, monitoring active, validation scripts ready.
• rollback plan
  • clear decision criteria:
    • when to rollback,
    • how to rollback,
    • expected time to restore service.

A frequent exam scenario: “Users report errors immediately after cutover.” Your response should include:

• triage steps (log review, monitoring alerts),
• immediate rollback decision process,
• communication plan to users and stakeholders,
• post-rollback root cause analysis and corrective action.

Managing the Migration Factory: Quality, Throughput, and Standardization

Execution scale requires operational discipline.

Quality in the migration factory:

• standardized infrastructure templates,
• automated environment provisioning,
• consistent identity configuration,
• repeatable testing scripts.

Throughput management:

• limit concurrent migrations if validation resources are constrained,
• schedule waves based on testing capacity, not only engineering capacity.

Standardization benefits:

• fewer human errors,
• faster onboarding of new team members,
• consistent reporting evidence.

In exams, if asked “How would you improve migration throughput?” you can answer with:

• automation, templates, pre-defined test suites, and factory processes,
• but emphasize you do not sacrifice quality gates.

Operational Readiness: Turning Migration Outputs Into Sustainable Operations

A workload in the cloud is not “done” until operations can run it safely.

Operational readiness checklist usually includes:

• monitoring dashboards and alert thresholds,
• incident response runbooks,
• escalation paths,
• on-call staffing expectations,
• backup/restore verification,
• maintenance processes (patching, scaling),
• access provisioning and deprovisioning processes.

A typical exam question is: “Explain the difference between deployment success and operational readiness.”
Strong answer:

• deployment success means it runs,
• operational readiness means the organization can support, detect issues, respond, and recover reliably.

Security During Execution: Evidence-Based, Not Checkbox-Based

Security should be treated as an execution control, not a final audit.

Security execution tasks:

• apply encryption at rest and in transit configurations,
• configure key management and access policies,
• ensure audit logs are enabled and centralized,
• validate security group/firewall rules align with least privilege,
• test access paths (including service accounts and admin roles).

If security is delayed until the end, you get “late fixes” that cost more.

Exam-friendly approach:

• tie security tasks to stage gates:
  • before cutover, you must have evidence that security controls are configured and tested.

Communication and Stakeholder Management During Delivery

Communication must match the migration intensity.

Communication artifacts:

• daily/weekly migration status,
• cutover announcement notices,
• incident updates during stabilization,
• post-cutover retrospective summary.

Stakeholders you communicate with:

• application owners,
• business users,
• IT service desk,
• security and compliance,
• external vendors (where applicable).

In exams, if asked “How do you manage stakeholder expectations?” you can score by discussing:

• explicit downtime windows,
• service-level commitments,
• transparency on migration progress and validation evidence,
• managing scope changes via change control.

Section 4: Governance, Risk Management, and Compliance for Cloud Migration Projects (UNISA IT Project Management / Risk Themes)

Governance ensures the project stays aligned with business goals, stays compliant, and remains controlled under uncertainty. Risk management reduces the likelihood and impact of failures—especially around security, data, downtime, and cost.

Governance Structure: Who Decides?

A governance model often includes:

• Steering committee
  • business + IT leadership; approves major decisions and escalations.
• Architecture review board
  • approves target architecture patterns and standards.
• Security and compliance approval authority
  • approves controls and evidence required for production.
• Change control board (CCB)
  • approves scope changes and manages schedule impact.
• Project management office (PMO)
  • consolidates reporting, ensures consistent project documentation.

In exam answers, describe the flow of decisions:

• teams execute within approved standards,
• exceptions require approval with recorded risk acceptance.

Risk Management Lifecycle (What to Include in an Exam Answer)

Use a lifecycle:

1. Identify risks
   • technical risks, people/process risks, vendor risks, compliance risks.
2. Analyze
   • likelihood/impact scoring; dependency mapping-based risk scoring.
3. Plan responses
   • mitigation, contingency, or acceptance.
4. Execute controls
   • apply mitigation actions; monitor triggers.
5. Review
   • update risk register; escalate when thresholds are exceeded.

Common cloud migration risks (and strong mitigation examples)

• Data loss or corruption
  • mitigate with integrity checks, incremental sync, tested rollback.
• Downtime overruns
  • mitigate with rehearsed cutover, phased cutover, rollback readiness.
• Security non-compliance
  • mitigate with landing zone policies, evidence-based sign-off, continuous scanning.
• Cost overruns
  • mitigate with tagging, budgets, reserved capacity strategy, FinOps monitoring.
• Skills and staffing gaps
  • mitigate with training, pairing, documentation, or managed services support.
• Dependency complexity
  • mitigate with dependency mapping and wave sequencing gate.
• Vendor lock-in concerns
  • mitigate by documenting portability choices, using abstraction patterns where feasible.

Risk Register: How to Structure It

A high-scoring risk register entry includes:

• risk description,
• triggering conditions,
• likelihood and impact score,
• mitigation actions,
• owner (named role),
• contingency plan,
• current status (open/mitigated/accepted),
• review date.

In exams, avoid vague entries like “risk of delays.” Use evidence-based phrasing:

• “Security evidence review may delay cutover because access to audit tooling is not yet available for the security team.”

Compliance and Evidence: Making Audit-Ready Outputs

Compliance in cloud migration means:

• meeting regulatory requirements,
• maintaining audit trails,
• ensuring data residency and retention rules,
• ensuring access and encryption requirements.

Evidence categories:

• configuration evidence (policies applied),
• operational evidence (logs and monitoring),
• testing evidence (security and integrity test reports),
• change evidence (cutover records, approvals).

A strong answer emphasizes:

• compliance is not “end-of-project paperwork,”
• it should be integrated into landing zone and execution stage gates.

Security Governance: Threat Modeling and Least Privilege

Security governance typically includes:

• threat modeling sessions early,
• defining identity roles (admin vs operator vs viewer),
• implementing least privilege access controls,
• ensuring separation of duties.

Threat model outputs:

• assumptions and threat boundaries,
• likely attack vectors (e.g., misconfigured storage, exposed endpoints),
• controls to mitigate vectors,
• validation tests to confirm controls.

Cost Governance: FinOps as a Control, Not a Finance Afterthought

FinOps governance includes:

• tagging policy
  • every resource tagged with application name, environment, owner, and cost center.
• budgets and alerts
  • budget thresholds and anomaly detection alerts.
• cost allocation
  • showback/chargeback approach.
• optimization workflow
  • identify over-provisioning, schedule scaling, right-size storage and compute.

Exams often test cost governance indirectly through scenario questions such as:

• “After migrating, monthly cloud bill increased by 35%.”
  Best answers show you:
• inspect which categories contributed (compute, storage, egress, logs),
• identify tagging failures and unplanned environments,
• implement budgets and automated controls.

Change, Auditability, and Traceability

Governance requires traceability:

• why a decision was made,
• what evidence supports that decision,
• who approved it.

Key exam points:

• decision logs and exception registers,
• traceability from requirements to acceptance criteria,
• sign-off records at stage gates.

If an application fails validation, governance should require:

• root cause analysis,
• corrective action plan,
• updated risk assessment if the failure indicates systemic risk.

Section 5: Exam-Style Practice: End-to-End Cloud Migration Management with Realistic Scenarios (South African University Case Preparation)

This section provides scenario-based practice that mirrors how university examinations in South Africa test applied understanding: structured responses, correct terminology, and clear linkage between project management controls and technical outcomes.

Scenario 1: Portfolio with Mixed Complexity and a Tight Deadline (Application Wave Planning)

Situation: A mid-sized organization has 12 applications. Three are business-critical and require near-zero downtime. Five are medium complexity with moderate dependencies. Four are low complexity but include regulated data.

Constraints:

• Security compliance evidence must be ready before production cutover.
• Developers are available for testing only during business hours.
• The business requires a first wave demo in 6 weeks to justify funding.

Your tasks (what an exam answer should contain)

1. How you would assess readiness
   • dependency mapping,
   • data classification for regulated apps,
   • initial infrastructure and landing zone readiness.
2. How you would create migration waves
   • foundations first (identity, network primitives),
   • then critical apps (but only if evidence gates can be met),
   • regulated apps after integrity validation approach is proven.
3. How you would estimate schedule
   • effort breakdown per application,
   • scheduling testing capacity,
   • risk buffer for data transfer variability.
4. How you would manage cutover
   • near-zero downtime apps use staged cutover with incremental sync and rehearsed rollback.

Strong exam framing (example outline)

• Wave 0: landing zone + shared platform validation.
• Wave 1: two critical applications (highest value) plus one medium dependency app.
• Wave 2: remaining medium applications after dependency confidence increases.
• Wave 3: regulated data apps after additional security evidence and integrity test scripts are validated.

Counter-argument and mitigation

A common incorrect approach is migrating low complexity apps first to “gain momentum.” While that feels safe, it can fail if:

• the landing zone remains unvalidated for production,
• operational readiness is incomplete for identity/security,
• regulated apps require more complex evidence that you delayed.

A high-scoring alternative:

• migrate at least one critical path dependency early to validate the hardest integration patterns—so later waves avoid repeated rework.

Scenario 2: Data Integrity Failure During Cutover (Execution Controls and Rollback)

Situation: During a cutover of a customer relationship application, a validation script reveals a mismatch in record counts after switching traffic. Users begin reporting missing historical entries within 15 minutes.

Constraints:

• There is a contractual downtime limit.
• Rollback must preserve the integrity of both the old and new systems.

What your exam answer should cover

1. Immediate triage
   • stop further traffic switching,
   • capture logs from both old and new environments,
   • check integrity comparison outputs and replication completeness.
2. Rollback decision
   • use pre-defined criteria from the cutover plan stage gate,
   • inform the steering committee and impacted stakeholders.
3. Rollback execution
   • revert traffic routing,
   • verify database consistency in the rollback environment,
   • confirm that no partial writes are causing cross-system inconsistencies.
4. Root cause analysis
   • identify whether the issue was due to:
     • incomplete data transfer,
     • schema mapping error,
     • transformation bug,
     • referential integrity constraints not satisfied.
5. Corrective action
   • update data migration scripts,
   • rerun integrity validation,
   • conduct a “rehearsal cutover” before the next attempt.

Why governance matters here

Even if technically you can “fix the data,” governance requires:

• documented incident timeline,
• evidence of corrective actions,
• updated risk assessment for similar applications.

Examiners typically look for:

• structured incident response,
• traceable evidence and sign-off,
• learning loops through retrospectives.

Scenario 3: Security Audit Finds Misconfigured Permissions (Compliance and Landing Zone Governance)

Situation: After migrating an internal payroll-related application, a security audit finds that some storage resources are accessible with overly broad permissions. The application itself works, but the configuration violates least privilege requirements.

What you must say in an exam answer

• identify that this is a governance failure, not only an application failure,
• describe how you would:
  • remediate permissions quickly,
  • implement policy-as-code in the landing zone,
  • enforce tagging and automated compliance scanning,
  • ensure evidence collection for audit.

Counter-argument: “We can just fix that app”

A high-scoring response explains why fixing only one app is insufficient:

• misconfiguration suggests the process for new environments lacks enforcement,
• other workloads might have similar issues,
• remediation must include platform controls:
  • guardrails,
  • automated policy checks,
  • standardized provisioning templates.

Scenario 4: Cloud Costs Increase by 35% After Migration (FinOps Controls and Optimization)

Situation: Two months after migration, the organization notices that monthly cloud spending increased by 35% compared to initial estimates.

To answer exam questions effectively, you should propose an investigation structured by cost categories.

Your analysis steps

1. Validate tagging and cost allocation
   • identify resources with missing tags or unknown owners.
2. Break down variance
   • compute, storage, network egress, managed services, logging.
3. Identify drivers
   • right-sizing opportunities,
   • scaling policies too aggressive or too slow,
   • data egress caused by inefficient integration,
   • logs generating higher ingestion than expected.
4. Corrective actions
   • set budgets and alerts,
   • implement automated scaling based on observed metrics,
   • optimize data transfer patterns (caching, batching),
   • tune log retention and sampling strategies.
5. Prevent recurrence
   • apply FinOps governance stage gate for future waves.

Exam-style conclusion

Cost increases are often predictable if you integrate FinOps earlier:

• without tagging standards and budgets,
• and without baseline measurement of workload utilization,
  cloud spend becomes uncontrolled.

Scenario 5: Multi-Team Coordination and Timeline Slippage (Project Management Discipline)

Situation: A program includes platform engineers, application engineers, security, and network teams. The first wave slips by 3 weeks because network firewall rules were approved late, and security evidence collection took longer than expected.

What a strong exam answer should include

• how you would restructure governance:
  • stage gates for security and network approvals,
  • earlier evidence requests,
  • parallelization where possible (e.g., build landing zone and draft templates while evidence is prepared).
• how you would adjust planning:
  • re-sequence dependent tasks,
  • update risk register and schedule baselines,
  • re-baseline only after change control approval.
• how you would improve stakeholder communication:
  • weekly plan and progress updates,
  • risk escalations with mitigation proposals.

Counter-argument: “The delay is just because teams are busy”

A high-scoring answer acknowledges workload constraints but emphasizes:

• delays often indicate governance and coordination gaps,
• project management must reduce dependencies bottlenecks through scheduling discipline and pre-approval workflows.

Scenario 6: Designing an Exam-Perfect Answer (Template for How to Write)

Exams often reward a consistent structure. Use this skeleton in practice responses:

1. Briefly restate the scenario and your goal
2. List assumptions and clarifying questions (if appropriate)
3. Provide an approach with steps
4. Include deliverables
5. Include risks and mitigations
6. Mention governance/approval points
7. Close with acceptance criteria or success metrics

This “shape” is crucial for many South African university assessments because it demonstrates you can manage complexity and communicate decisions clearly.

Final Consolidation: The Cloud Migration Management Checklist (Quick Exam Reference)

Use this checklist to prepare for written exams and case studies:

• Planning

  • Portfolio assessment done; dependencies mapped.
  • Migration waves and sequencing logic defined.
  • Estimates include testing, security evidence, and operational readiness.
  • Change control process active.

• Execution

  • Migration factory or repeatable process exists.
  • Functional, data integrity, security, performance, and integration tests defined.
  • Cutover plan includes rollback and rehearsals.

• Governance

  • Stage gates for security/compliance approvals.
  • Risk register maintained with owners and triggers.
  • Decision logs and traceability maintained.

• FinOps and Operations

  • Tagging standards and cost allocation in place.
  • Budgets and alerts configured.
  • Monitoring, runbooks, incident response, and backup/restore validation completed.

Summary

Managing cloud migration projects requires structured project planning, disciplined execution controls, evidence-based security and compliance, and continuous governance across schedule, risk, and cost. A high-performing migration program treats the landing zone as a foundational deliverable, organizes work into waves with explicit exit criteria, and ensures that validation includes both data integrity and operational readiness. With stage gates, a well-maintained risk register, and FinOps-aware governance, organizations can reduce failures and turn migration into a controlled transformation—exactly the kind of applied management understanding South African university assessments expect in IT project management–aligned modules (including Unisa MNG0001-style management foundations and similar course outcomes).