Cloud readiness and CCoE design at a Fortune 100 commercial-truck OEM

The situation

A Fortune 100 commercial-truck OEM was at the start of a multi-year cloud journey. The technology organization had hundreds of applications spanning manufacturing, supply chain, dealer networks, telematics, and enterprise back-office systems. Some had been running for two decades on hardware long out of vendor support; others were modern Java and .NET stacks. Leadership had made the strategic call to move to public cloud, but the technology group had no shared language for which workloads belonged there, in what order, or under what operating model.

They had also seen, across peer organizations, what happens when a cloud program is launched without a Center of Excellence: every business unit picks a different cloud provider, security and identity become unmanageable, and the cost-savings business case quietly disappears within twelve months.

The mandate was concrete: assess cloud readiness across the IT organization, design a Cloud CoE operating model that was credible to both engineering and audit, and apply both to a real subset of the application portfolio so the program could begin migration with confidence.

What we did

1. Cloud-readiness diagnostic across IT operations. Used an ITIL-grounded cloud-readiness assessment covering planning, opportunity management, guideline development, vendor and partner engagement, and cloud enablement / workforce. Produced maturity scoring across each domain and identified the top remediation items the organization needed to handle before any large-scale migration could safely begin.
2. Cloud Center of Excellence (CCoE) operating-model design. Designed the CCoE across five functional areas: Strategic Planning & Investment, Cloud Opportunity Management, Guideline Development, Vendor & Ecosystem Engagement, and Cloud Enablement. Build / Operationalize / Scale phasing with maturity gates and explicit ownership for each phase. Designed for hand-off to a client-led team, the CCoE was meant to outlive the engagement.
3. Application-portfolio fit-for-cloud filter (803 → 133). Built a multi-stage rubric covering application lifecycle, business function, source-code availability, application stack, IAM integration, dependencies, database review, security review, and operational readiness. Applied it to the production portfolio, narrowing 803 applications to 133 cloud-bound candidates with clear rationale for the 670 left behind.
4. Migration approach decision framework. Per-application migration approach (rehost / refactor / rebuild) with cost, risk, and timeline implications spelled out. Plus a preliminary fit-for-cloud workflow the platform team could use for new applications going forward, not just the in-flight portfolio.
5. Remediation roadmap with knowledge transfer. Tactical remediation items (90-day) tied to mission-critical go-live dates. Strategic items (12-24 months) tied to the CCoE rollout. Knowledge-share sessions with the existing platform team so the work survived the engagement.

Outcomes

• Application portfolio narrowed from 803 to 133 cloud candidates with documented rationale for the 670 deferred
• Five-function Cloud CoE operating-model spec, phased Build → Operationalize → Scale
• Maturity scoring across cloud-readiness domains with prioritized remediation list
• Per-application migration approach (rehost / refactor / rebuild) with risk and cost implications
• Knowledge transfer to the in-house platform team, the program continued under client ownership after the engagement

What was hard

Cutting the portfolio from 803 to 133 was the easy half. The hard half was the social work around it: every "no" was an application owner who believed their system absolutely belonged in cloud. The rubric was designed to take the conversation from opinion to data, but data only goes so far when an application owner is being told their pet project is a rehost candidate at best. We ended up running individual readouts with the top 30 application owners, not because the rubric was wrong, but because the program needed those owners on board for migration to actually happen.

The CCoE design also had to thread a needle between engineering autonomy (modern teams hated the idea of a centralized review board) and enterprise control (security and procurement could not have a free-for-all). The phased model, start with strong central governance, deliberately decentralize as the platform matures, was the negotiated answer.

Selected artifacts

• Cloud-readiness diagnostic instrument. ITIL-based maturity assessment across 5 cloud-readiness domains
• Cloud CoE operating-model spec. Functional-area definitions, phased rollout, maturity gates
• Application fit-for-cloud rubric. Multi-stage filter from full portfolio to cloud-bound candidates
• Migration-approach decision framework. Rehost / refactor / rebuild decision tree per application class

Public-cleansed templates and frameworks drawn from engagements like this one are in our resources library.