HCSP-Cloud Migration common mistakes
HCSP-Cloud Migration · Understand the traps and how to avoid them.
Treating the six R's (rehost, replatform, refactor, repurchase, retire, retain) as a fixed decision made once at the start of the programme, then answering assessment questions as if the disposition cannot change when new dependency data arrives.
Study material often presents the migration strategies as a simple ordered list, so candidates memorise the labels and pick whichever sounds most modern rather than reasoning about constraints such as licensing, latency, or regulatory data residency.
What to do instead
For each workload, rehearse a short decision record: business driver, technical blockers, cost of change, and the exit path if the chosen strategy fails. Practise justifying why a regulated mainframe workload with hard real-time dependencies stays in retain or replatform rather than refactor, and be ready to revise the disposition when discovery reveals a hidden dependency.
Skipping a formal discovery and dependency-mapping step and moving straight to sizing target infrastructure, so the assessment answers omit undocumented integrations, batch windows, and hard-coded endpoints.
Candidates equate assessment with cost estimation and assume the application inventory they are given is complete; in practice most migration incidents trace back to an unknown dependency discovered only at cutover.
What to do instead
Always place automated discovery and dependency mapping before sizing in any sequenced answer. Describe the artefacts it must produce: network flow records, scheduled job inventories, credential and certificate inventories, and a validated application-to-infrastructure map signed off by application owners.
Producing a migration plan with a single go-live date and no wave structure, rollback criteria, or acceptance gates between waves.
Exam scenarios often ask for 'the plan' and candidates write a linear project schedule, forgetting that migration planning questions usually test sequencing, risk containment, and the ability to stop safely between increments.
What to do instead
Structure plans as waves grouped by shared dependency or risk profile, each with entry criteria, exit criteria, a rollback trigger, and a named decision owner. State explicitly what is validated at the end of each wave before the next begins.
Assuming a lift-and-shift of an application automatically carries its behaviour, ignoring hard-coded IP addresses, local file paths, session state held on the host, and OS-level dependencies.
Rehost is described as the lowest-effort strategy, so candidates under-report the remediation work needed to make a server image run in a new network and identity environment.
What to do instead
For every rehost answer, list the configuration surface that must be re-pointed: DNS and load-balancer names, connection strings, certificate stores, time sources, agent software, and any state written to local disk. Note where replatforming a component is cheaper than preserving a fragile host-bound dependency.
Designing data migration as a single bulk copy on cutover night without a change-data-capture or delta phase, and without a reconciliation step comparing source and target.
Data migration questions look like storage questions, so candidates focus on transfer throughput and forget that most data cuts fail on consistency, not speed.
What to do instead
Always describe a phased approach: initial bulk load, ongoing replication or CDC for changes, a freeze or quiesce window, then row-count and checksum reconciliation with a documented tolerance. Include a dry run and a measured rollback that restores the source as authoritative.
Migrating a relational database by moving only schema and rows while ignoring stored procedures, sequences, triggers, collation, character sets, and query-plan behaviour.
Schema conversion tools report high automatic-conversion rates, which candidates take as completeness, but the residual objects and performance characteristics are where production failures occur.
What to do instead
Enumerate the non-table objects explicitly in any database migration answer, state how each is converted or rewritten, and require a performance baseline comparison of the top queries before and after migration rather than only a functional test.
Planning network and identity migration as an afterthought, treating connectivity, DNS, routing, and directory trust as things that will be 'configured during cutover'.
Infrastructure questions pull attention toward compute and storage sizing, and candidates underestimate how many cutover failures are name-resolution or trust failures rather than server failures.
What to do instead
Give network and identity their own workstream with their own test gates: hybrid DNS resolution in both directions, routing and firewall rules validated before any workload moves, and directory or federation trust proven with test accounts. State the order in which these must be in place relative to the first workload migration.
Writing a cutover runbook that lists tasks but omits durations, owners, verification commands, communication points, and the precise decision point at which rollback is triggered.
Candidates confuse a task list with a runbook and assume the reader knows how long each step takes and who is accountable when a check fails.
What to do instead
Write runbooks with timestamped steps, a named owner per step, the exact verification that proves success, expected duration, and a hard rollback deadline after which forward-fix is the only option. Include the stakeholder communication cadence and the criteria for declaring cutover complete.
Declaring migration success on the basis that the application starts and responds, without business-level validation, performance comparison against the pre-migration baseline, or a hypercare period with defined exit criteria.
Technical smoke tests are easy to describe and feel conclusive, so candidates stop there and miss the acceptance and stabilisation stages that the validation domain is really testing.
What to do instead
Define validation at three levels: technical health checks, business transaction tests executed by business owners, and performance against a captured baseline. Then specify a hypercare window with heightened monitoring, a defect triage path, and explicit exit criteria before the old environment is decommissioned.
Treating post-migration operations as 'the same but in the cloud', leaving tagging, cost allocation, patching, backup retention, and drift detection out of the target operating model.
Candidates concentrate their study on getting workloads across the line and assume existing operational processes transfer unchanged, missing that governance and cost control are separate examinable domains with their own controls.
What to do instead
For any post-migration scenario, state the concrete controls: a mandatory tagging schema tied to cost centres, budget alerts and anomaly detection, patch and backup policies mapped to recovery objectives, configuration drift detection, and a periodic optimisation review that rightsizes and removes orphaned resources. Tie each control to an accountable owner.