Cabinet Office shifts Falcon migration to M365 via ICS/DESNZ, cost cut, red risk

The Cabinet Office has quietly handed responsibility for its long-running, much-delayed migration from Google Workspace to Microsoft 365 (M365) to another government unit, effectively changing the delivery model for the Falcon IT Platform Refresh and Migration programme and halving the project’s reported whole-life cost estimate — even as the programme remains a “red” delivery confidence risk and the actual user migration has yet to begin in earnest.

Background and overview​

The Falcon programme — launched in 2022 — is a two‑strand effort to modernise the Cabinet Office’s official IT platform and to migrate around 15,000 department users and their business data from Google Workspace to Microsoft 365. The programme has been repeatedly re‑scoped and re‑timed, and its governance has been shifted around as Whitehall reorganised central delivery functions.
Until recently the Cabinet Office planned to build a bespoke departmental IT platform alongside an in‑house migration delivery model. That approach has now been revised: the department’s digital services will move under the government’s shared Integrated Corporate Services (ICS) capability, managed by the Department for Energy Security and Net Zero (DESNZ). The change was driven by a departmental review concluded and recorded in the government major projects portfolio reporting, which concluded that the original plan — to design and build the platform entirely in‑house — was not the most cost‑effective option.
Key points in the new approach:

• The migration remains aimed at replacing Google Workspace with Microsoft 365, aligning the Cabinet Office with the majority of central government departments.
• Responsibility for delivering the platform and migration will be taken on by the shared ICS service within DESNZ, rather than being built exclusively by the Cabinet Office.
• Government reporting shows a substantial reduction in the programme’s whole-life cost estimate following the change of approach — falling from roughly £50–52 million to an estimated £23 million — largely by avoiding bespoke platform build costs and by securing migration resource from Microsoft and partners at no direct investment cost.
• Despite the revised delivery route, the programme’s delivery confidence remains Red, and the pilot phase has been delayed; the migration of staff and data has not yet been completed.

This shift is significant for both practical delivery and for wider public‑sector IT policy: it marks an explicit preference for shared, central services over department‑specific bespoke builds, and exposes both the benefits and risks of consolidation in government IT delivery.

---

Why the migration matters: interoperability, security and future tools​

Moving a major department from Google Workspace to Microsoft 365 is not just an IT refresh — it’s a strategic interoperability and productivity decision with implications for collaboration, security management, procurement, and how the department will be able to leverage emerging Microsoft‑centric services and AI capabilities.

• Interoperability: Many government partners and suppliers already use Microsoft tools as their default productivity stack. Differences in file formats, collaboration workflows, and sharing models can create friction when departments must exchange documents, co‑author files, or join the same collaboration spaces. The Cabinet Office’s own programme documentation made the case that aligning on M365 would simplify cross‑departmental working and reduce friction.
• Security and data classification: The Cabinet Office handles Official‑level information and requires a platform that can be configured to meet the Government Security Group and National Cyber Security Centre expectations for data handling, information classification, and access control. Moving to the central government‑standard M365 environment promises a clearer route to consistent security baselines, but it also requires careful design to ensure configuration, retention, and classification controls are correct for Official‑level workloads.
• Future capability, including AI: The move has been pitched as enabling the Cabinet Office to take advantage of Microsoft’s next‑generation productivity and AI features that are being adopted across government. That can be a persuasive operational benefit, but it also introduces questions around data residency, AI model governance and how sensitive content is treated by third‑party services.

---

Timeline, contracts and costs: what changed​

The Falcon programme timeline and costs have been subject to several resets and governance changes.

• Initial work began in May 2022. Early public procurement notices and programme entries estimated whole‑life costs in the region of £50–52 million, with a planned completion window originally around March 2025 (then extended in subsequent reporting).
• In 2023 the Cabinet Office awarded a technical partner contract to Capgemini (public reporting placed that contract in the low‑teens of millions of pounds) to support platform delivery and migration activities.
• A separate migration delivery contract with Microsoft was signed and later terminated after a discovery phase; the department paid for discovery work but stopped the three‑year migration contract early, invoking contractual rights to terminate after discovery. The Microsoft discovery work reportedly cost the department a fraction of the anticipated full contract value.
• Following review, the Cabinet Office concluded that building and operating a bespoke platform itself was not the most cost‑effective path. The approved alternative is to move services into ICS, the shared corporate service run out of DESNZ, and to secure migration resource "from Microsoft and partners at no investment cost" — a statement that implies Microsoft and delivery partners will provide migration support under commercial or inter‑departmental arrangements, reducing direct Cabinet Office capital outlay.
• The net effect is a headline reduction in reported whole‑life cost for Falcon from around £50–52 million to about £23 million, according to programme reporting. However, such headline figures require careful reading: reduced vendor spend and platform build costs may be counted as departmental savings, but shared service charges, ongoing costs and risk contingencies can materialise later in other budget lines.

---

NISTA, governance and the red rating​

The programme sits on the Government Major Projects Portfolio and has been subject to formal delivery confidence assessments. The Infrastructure and Projects Authority’s functions were subsumed into the new National Infrastructure and Service Transformation Authority (NISTA), a joint unit of HM Treasury and Cabinet Office, which now provides oversight and assurance for major projects.

• The Falcon programme continues to carry a Red delivery confidence rating in recent GMPP reporting. A Red rating indicates that successful delivery appears unachievable unless major changes are made.
• NISTA’s assessment highlights resource constraints in transitioning the Cabinet Office business units within planned timeframes and notes pilot delays — the pilot was projected to complete later than originally planned, contributing to the Red classification.
• The governance move to ICS and the involvement of DESNZ reflect a formal intervention to change the delivery model and reduce cost, but the NISTA Red rating shows that organisational and resourcing risks remain significant.

---

Technical realities: migration complexity and common pitfalls​

Large‑scale productivity migrations are notoriously complex. Migrating email, calendars, contacts, files, shared drives, retention policies and user workflows from Google Workspace to Microsoft 365 is more than a copy operation: it requires mapping different collaboration models, security models and governance rules.
Common technical challenges include:

• Differences in file collaboration semantics (Docs/Sheets vs Word/Excel/OneDrive/SharePoint) and how comments, versions and permissions are represented.
• Mapping Google Shared Drives to SharePoint team sites or OneDrive for Business while preserving inheritance and access control.
• Preserving granular permissions and external sharing settings to ensure no unintended data exposure during cutover.
• Retention, archiving and message‑hold policies. Migration tooling can fail to capture items managed by message‑retention policies, leading to perceived data loss unless policies are disabled or reconciled pre‑migration.
• Authentication and service account limitations — recent platform changes in APIs, OAuth flows, and security policies can block automated exports unless tooling and admin settings are carefully configured.
• Bulk migration throughput and throttling: moving tens of terabytes of content for thousands of users can trigger provider rate limits and require staged migration windows.
• End‑user experience and training: preserving critical workflows, add‑ins and integrations (for example, custom Gmail add‑ons or Google App Script automations) often means rebuilding or replacing functionality in the new platform.

Lessons from real-world migrations suggest avoiding the temptation to treat the project as a single big cutover. Successful migrations are staged, tested and iteratively refined, with resilient rollback and verification steps.

---

Procurement and vendor-management lessons​

This programme’s evolution exposes typical public‑sector procurement and vendor management challenges.

• Early termination of a migration delivery contract after discovery underscores the importance of phased contracting and robust gate design. Discovery phases are valuable, but procurement should be structured so that outcomes and next steps are predictable and contracts remain aligned with business case options.
• The shift to a shared service model (ICS) aims to centralise capability and reduce duplication. That can deliver economies of scale but creates single points of dependency. If ICS lacks capacity or clear service level agreements for tenant migrations, the Cabinet Office may experience new bottlenecks.
• The apparent reliance on “migration resource from Microsoft and partners at no investment cost” should be scrutinised. While vendors often provide migration assistance as part of enterprise deals, those services typically come with limits, conditions, or tradeoffs — such as constrained guarantee levels, restrictions on scope, or expectations that the department will provide significant internal resource for project management and remediation.
• Public‑sector projects would do well to ensure robust commercial terms that include clear deliverables, transparent cost‑saving calculations and contingency funding for unexpected migration remediation activities.

---

Risks that remain — operational, security, political​

Even with the cost‑saving headline, the move does not remove all risks.
Operational and delivery risks:

• The Red rating persists because resourcing the business‑unit transition remains uncertain. ICS may save build costs, but it must still execute migrations at scale and integrate Cabinet Office business needs into its shared roadmap.
• The pilot delay — with the pilot’s completion date pushed — increases the probability of further slippage and risk of rushed cutovers that harm business continuity.

Security and compliance risks:

• Migration windows and permission re‑mapping are hotspot periods for accidental over‑sharing. The department must ensure elevated audit, centralised review and automated checks are in place during and immediately after migration waves.
• AI tools and new features can be powerful productivity multipliers but introduce governance questions about model access to Official data, telemetry, and potential leakage to vendor cloud services. Clear policies and configuration guardrails will be essential.

Political and reputational risks:

• A high‑profile department like the Cabinet Office carries additional scrutiny: programme delays, cost revisions and contract terminations attract media and Parliamentary attention. The programme’s shifting budgets and continuing Red rating will be cited in debates about major‑project oversight and the value of bespoke builds vs shared services.

---

Strengths and potential upsides​

Despite the problems, there are clear strengths to the revised approach.

• Cost discipline: Moving away from a bespoke platform build avoids upfront capital expenditure and reduces duplication. The revised estimate halving headline whole‑life cost (from ~£50m to ~£23m) demonstrates what shared services can deliver for like‑for‑like capability.
• Standardisation: Aligning with the central government standard stack reduces friction across cross‑department workflows and simplifies onboarding for partner organisations that already use Microsoft technology.
• Shared capability and procurement leverage: Using ICS leverages established delivery pipelines, contract vehicles, and standard operating models that smaller, department‑specific projects struggle to implement consistently.
• Vendor support for migration: Securing migration resource from Microsoft and partners at little or no direct investment cost allows the Cabinet Office to reduce upfront supplier invoices and reallocate internal budget to change management and training.

These positives matter — if the shared service model is adequately resourced and contractually committed to deliver migrations at the necessary pace.

---

Recommendations and best practices for government and large organisations​

For any large organisation contemplating or executing a Workspace‑to‑M365 migration, the following practical steps reduce risk and improve outcomes:

• Establish a phased migration strategy:
• Run small, well‑instrumented pilots that exercise all migration paths: mail, calendar, contacts, user drives, shared drives and application integrations.
• Use iterative waves to scale lessons learned before wider roll‑outs.
• Manage governance and security early:
• Define a target security baseline that maps Google controls to Microsoft equivalents.
• Freeze or reconcile retention and MRM policies in discovery so migration tools do not mislabel content as missing.
• Plan for permissions and shared spaces:
• Inventory shared drives and external shares; agree business rules for how these are mapped into SharePoint and OneDrive.
• Automate permission export/import and verify via sampling and audit trails.
• Invest in workforce change:
• Provide role‑based training, quick‑start job aids, and dedicated support channels during cutover windows.
• Preserve productivity by identifying and replicating critical macros, add‑ins or integrations.
• Secure commercial clarity:
• If migration assistance is provided by vendors at “no cost,” get details in writing: scope limits, SLAs, remediation guarantees and liability allocation.
• Retain contingency funding for edge cases — data remediation, compliance holds, or custom export/import issues.
• Build robust verification and rollback:
• Establish acceptance criteria, automated verification steps and snapshot backups for critical mailboxes and shared repositories.
• Rehearse rollback steps and maintain parallel access where possible during transition.
• Use independent assurance:
• Major programme reporting benefits from independent gateways and external assurance that triangulate progress, risk exposure and financials.

---

What to watch next​

The Falcon programme’s future success depends on several near‑term indicators:

• ICS capacity and delivery plan: whether ICS (DESNZ) publishes a clear, resourced migration plan with timelines and target completion waves for Cabinet Office BUs.
• Pilot outcomes: how the pilot (projected for later completion than originally planned) performs on migration success rates, data fidelity, and user acceptance.
• Resourcing and SLAs: commitments from Microsoft and delivery partners about the scope and limits of “no investment cost” migration resources.
• NISTA monitoring: whether the programme’s delivery confidence rating improves as actions from the gateway assurance are implemented.
• Operational continuity: whether the Cabinet Office can maintain business continuity for ministers and critical teams during staged migrations.

---

Conclusion​

The Cabinet Office’s decision to hand its faltering Google Workspace to Microsoft 365 migration to a central shared service is both pragmatic and revealing. Pragmatic because it acknowledges the value of scale, standardisation and shared capability over bespoke, department‑by‑department engineering. Revealing because it illustrates endemic challenges in public sector major projects: scope creep, procurement friction, resourcing constraints and the difficulty of planning across organisational boundaries.
The move to ICS and the headline cost reduction create breathing room and offer a credible path to delivery — but they are not a panacea. The programme’s Red rating, pilot delays, and the unresolved practicalities of migrating thousands of user accounts and petabytes of collaboration content underscore that the hardest work — technical migration fidelity, permissions governance, staff change and security assurance — remains ahead.
Success will depend less on headline cost reductions and more on disciplined delivery: realistic phased plans, rigorous technical design, transparent commercial terms with partners, and the investment in the human work of change management. If those elements come together, the Cabinet Office can achieve the interoperability and tooling benefits it seeks. If not, this will remain another cautionary example of how large public‑sector IT transformations can stall even when the business case is clear.

---

Source: theregister.com UK Cabinet Office abandons stalled Microsoft migration