GRSOE Cloud Migration — PM Challenges & How I Managed Them

Representative GRSOE scenario

Discovery showed that the application depended on more than its primary database. Identity services, recordkeeping interfaces, document generation, notifications, batch jobs, file transfers, service accounts and certificates all supported the end-to-end enrolment journey. A legacy batch process surfaced after the initial inventory.

Why it mattered

The application could appear healthy after migration while a downstream business process silently failed. The new dependency also affected test scope, cutover sequencing and ownership.

What I did as PM

• Convened application, integration, infrastructure and business SMEs to validate the dependency and assess impact.
• Assigned a technical owner, added the component to the migration backlog and updated the end-to-end dependency map.
• Added a formal dependency-attestation checkpoint before scope and cutover approval.
• Expanded integration, rehearsal and business-process tests to cover the newly identified path.

Communication and escalation

I reported the dependency as a risk, not a surprise failure: its business impact, schedule exposure, assigned owner and mitigation were visible in cross-workstream reviews. Any critical-path effect was raised to the steering committee with recovery options.

Representative GRSOE scenario

Once stakeholders knew the application was moving to Azure, requests appeared to redesign enrolment screens, change reports and improve workflows. Some changes were necessary for cloud compatibility; others were desirable enhancements.

What I did as PM

• Separated migration-critical requirements from discretionary business enhancements.
• Recorded each new request in the change log and asked solution, testing and business leads for impact estimates.
• Presented cost, schedule, resource, regression-testing and cutover-risk impacts to the change authority.
• Placed approved non-critical items in a post-migration roadmap so stakeholders were heard without destabilizing the migration.

Communication and escalation

I explained that the choice was not simply “yes” or “no.” It was whether the value justified the additional migration risk and what trade-off leadership was prepared to approve.

Representative GRSOE scenario

The infrastructure team favoured rehosting on Azure virtual machines to reduce near-term change, while architecture advocated re-platforming selected components to managed Azure services for supportability and longer-term value.

What I did as PM

• Established clear decision criteria: delivery time, cost, technical risk, security, operability, skills, support model and strategic alignment.
• Facilitated an option workshop with architecture, application, infrastructure, security, operations and finance.
• Requested a time-boxed proof of concept where assumptions needed evidence.
• Captured the architect’s recommendation, alternatives and rationale in the decision log before build began.

Communication and escalation

I translated the options into business trade-offs for sponsors. Where consensus was not possible, I escalated a decision package with impact, options, recommendation and decision deadline.

Representative GRSOE scenario

The application team was ready to deploy, but environment prerequisites such as network connectivity, private endpoints, DNS, firewall rules, identity access and monitoring were incomplete.

What I did as PM

• Broke “environment ready” into testable prerequisites with owners, planned dates and acceptance evidence.
• Linked prerequisites to the integrated schedule so their effect on the critical path was visible.
• Ran short, focused readiness checkpoints with infrastructure, security and application leads.
• Resequenced work: teams advanced test cases, deployment scripts, training and documentation while blockers were resolved.

Communication and escalation

I escalated overdue prerequisites with the exact blocked activity, critical-path impact, recovery date and help required—not a generic red status.

Representative GRSOE scenario

Security review raised findings involving service accounts, secrets and certificates, privileged access, encryption, database permissions or network rules. Production approval depended on remediation and evidence.

What I did as PM

• Integrated security activities into the plan from design onward rather than treating approval as a final gate.
• Recorded each finding with severity, accountable owner, target date, remediation plan and evidence requirement.
• Made unresolved critical findings explicit go-live blockers and scheduled re-review time.
• Protected specialist capacity for security retesting before the go/no-go meeting.

Communication and escalation

Weekly reporting showed residual risk and approval status. Items approaching tolerance were escalated early to the sponsor and security authority with schedule options.

Representative GRSOE scenario

The business approved a six-hour outage, but a timed rehearsal showed that extracting, moving and validating the database and documents would take about eight hours.

Why it mattered

Proceeding without correction could breach the approved change window, disrupt enrolment activity and force a late rollback.

What I did as PM

• Raised a high-priority cutover risk and convened data, application, cloud and business leads.
• Asked the technical team to evaluate optimization, pre-staging and a smaller final delta migration.
• Updated the critical path, cutover runbook and contingency decision times.
• Scheduled another full-volume, timed rehearsal using the same validation criteria.

Communication and escalation

Leadership received the measured gap, business impact, remediation plan and the date when new evidence would be available. If timing remained outside tolerance, I would seek an expanded window or recommend no-go.

Representative GRSOE scenario

A test migration showed a mismatch between source and target record totals, and a sample of financial or enrolment values did not meet agreed reconciliation tolerances.

What I did as PM

• Stopped the migration checkpoint from being signed off and opened a high-severity issue.
• Assigned root-cause analysis to the data migration lead with support from application and business data owners.
• Required correction of the migration logic, a clean rerun and repeatable reconciliation reporting.
• Kept the issue open until quantitative thresholds were met and the accountable data owner approved the result.

Communication and escalation

I communicated the affected data domain, magnitude, business impact and next checkpoint without minimizing the discrepancy. A failed mandatory criterion remained visible as a go-live blocker.

Representative GRSOE scenario

A user could complete enrolment in the migrated application, but the resulting transaction did not reach a retained recordkeeping system. The application test passed; the business journey failed.

What I did as PM

• Classified the issue by end-to-end business impact, not the health of one component.
• Created a joint triage involving application, integration, network and target-system owners.
• Clarified one accountable incident owner while specialists investigated connectivity, identity, routing and message-handling evidence.
• Required a retest of the original business scenario plus regression of related interfaces.

Communication and escalation

Status updates described customer and operational impact, not just technical symptoms. The issue was escalated against the business-journey release criterion.

Representative GRSOE scenario

Functional testing passed, but peak-load testing showed response times materially slower than the agreed baseline—for example, five to six seconds where the acceptance threshold was closer to two.

What I did as PM

• Raised a release risk and confirmed that the test workload and acceptance threshold were valid.
• Coordinated application, database and Azure engineering teams to isolate the bottleneck.
• Tracked tuning actions and any cost or architecture consequences of scaling changes.
• Required a repeat test using the same workload, data volume and success criteria.

Communication and escalation

I translated response-time results into user and operational impact. If remediation required more capacity, the sponsor also saw the revised cost forecast and decision.

Representative GRSOE scenario

Accessibility testing found keyboard traps, unclear focus order, missing accessible names, screen-reader announcements or form-error handling that could prevent some users from completing enrolment.

What I did as PM

• Kept accessibility within the definition of done and production readiness, not as post-release cleanup.
• Triaged findings by severity, affected journey and user impact with accessibility, QA, design and application leads.
• Tracked critical barriers as release blockers and scheduled remediation plus regression testing.
• Required accessible test evidence and business acceptance before closure.

Communication and escalation

I explained the real user barrier and release risk in plain language, rather than reporting only a technical standard reference. Any proposed exception required accountable business and compliance review.

Representative GRSOE scenario

The technical team was ready for user acceptance testing, but the business entered a peak enrolment period and subject-matter experts had limited capacity.

What I did as PM

• Worked with the sponsor to name primary testers and trained delegates rather than relying on one SME.
• Prioritized critical business journeys, regulatory or financial checks and high-risk integrations first.
• Reserved test windows in advance and provided prepared data, scripts and daily support to reduce tester effort.
• Tracked execution, blocked tests, defects and sign-offs daily; I did not substitute technical testing for business acceptance.

Communication and escalation

I showed the sponsor the acceptance gap and milestone impact early. Where coverage was insufficient, the choice was additional qualified capacity, a revised window or a release-date decision.

Representative GRSOE scenario

A business lead called a defect Severity 1, a developer considered it Severity 3 and QA assessed it as Severity 2. Competing opinions threatened to distort the release decision.

What I did as PM

• Established severity criteria before testing: impact, users affected, data or security exposure, business-journey failure and workaround availability.
• Separated severity (impact) from priority (repair order).
• Facilitated daily triage with QA, product/business and technical leads, using evidence rather than job title.
• Required explicit business-risk acceptance for lower-severity items deferred to the post-production backlog.

Representative GRSOE scenario

Security testing or network readiness ran approximately two weeks late, threatening the start of performance testing and the planned production window.

What I did as PM

• Validated the root cause, completed work, remaining effort and predecessor/successor dependencies.
• Recalculated the critical path rather than automatically moving the go-live date.
• Evaluated recovery through resequencing, safe parallel work, focused resources, scope choices and additional test windows.
• Updated the integrated plan and checked that acceleration did not create quality, security or burnout risk.

Communication and escalation

I escalated problem + impact + options + recommendation + decision required. Executives received a decision package, not simply a report that the project was late.

Representative GRSOE scenario

Load-test results, data growth or non-production environments indicated that forecast cloud consumption could be about 20% higher than the approved estimate.

What I did as PM

• Reconciled actual and forecast costs with cloud engineering, finance and the application owner.
• Separated one-time migration expense from recurring run cost and identified the main cost drivers.
• Asked the technical and FinOps specialists to assess safe options such as rightsizing, schedules for non-production resources, storage tiers and reservation or commitment approaches.
• Updated the forecast, benefits case and contingency position; any material variance went through change control.

Communication and escalation

I reported the annualized business impact, confidence range, operational trade-offs and recommendation. Cost reduction was never allowed to undermine availability, security or test validity.

Representative GRSOE scenario

During the cutover weekend, a mandatory reconciliation or critical business-journey check failed. A senior stakeholder wanted to continue because customer communications and resources were already committed.

What I did as PM

• Returned the discussion to the approved go/no-go criteria and current evidence.
• Confirmed the issue’s business impact, uncertainty, time remaining and rollback deadline with accountable leads.
• Presented proceed, pause or rollback options with consequences and made a clear recommendation.
• Ensured the authorized decision-maker made and documented the decision; criteria were not redefined under pressure.

Communication and escalation

I remained factual and calm: what failed, why it mattered, whether a safe workaround existed and how long we had before rollback became unsafe.

Representative GRSOE scenario

The production runbook sequenced the change window: maintenance mode, data freeze, final migration, reconciliation, application validation, business smoke testing, go/no-go and traffic cutover.

What I did as PM

• Confirmed every runbook step had an owner, predecessor, planned duration, validation evidence and tolerance.
• Opened one command channel, one live status log and a fixed checkpoint cadence.
• Used closed-loop reporting: the owner announced start, completion and evidence; the coordinator recorded status and time.
• Protected technical teams from conflicting requests and routed issues through a named incident lead.
• Watched elapsed time, decision deadlines and rollback triggers while technical leads focused on execution.

Communication and escalation

Teams received task-level instructions; executives received concise checkpoint status, forecast completion, top risk and decisions. Only designated communicators issued broader stakeholder updates.

Representative GRSOE scenario

The migration could require rollback if reconciliation failed, a critical journey remained unavailable, a material security exposure emerged or the outage window crossed a safe recovery threshold.

What I did as PM

• Required the rollback plan and decision rights to be agreed and rehearsed before the production weekend.
• Defined objective triggers, the latest safe decision time and the authority who could invoke rollback.
• Included traffic reversal, source-system restoration or reactivation, source validation, data-change handling and user communication.
• Confirmed staff, access, backups and support teams remained available until rollback was no longer possible.

Communication and escalation

Stakeholders knew in advance what would trigger rollback and how service would be restored. This reduced debate during a time-critical event.

Representative GRSOE scenario

After launch, users reported intermittent slow response, a batch process failed and some notifications were delayed. The service was live, but it had not yet reached normal operational stability.

What I did as PM

• Activated a structured hypercare roster with application, Azure, integration, database, service desk, business and operations representation.
• Ran daily triage and tracked availability, performance, batch completion, integration errors, ticket volume and business impact.
• Assigned incident owners and resolution targets, linked repeat issues to root-cause problems and kept workarounds visible to support staff.
• Used predefined exit criteria such as stable service levels, no open critical incidents, controlled ticket trend, completed knowledge transfer and operational acceptance.

Communication and escalation

Business updates focused on impact, workaround, recovery forecast and next update time. Major incidents followed the established escalation path; routine noise stayed within the delivery team.