Orange County Seeks Info on Migrating Off Azure in a Cloud Exit RFI

Background​

Why this RFI matters: the politics and the practice of leaving a hyperscaler​

• It publicly acknowledges a county-level willingness to consider vendor diversification or a platform change at scale.
• It sets a formal procurement trail that vendors and consulting firms must respond to, creating an arena for commercial and technical proposals.
• It forces a practical reckoning with cloud exit mechanics — the technical, contractual and operational tasks required to successfully leave a provider without disrupting critical public services.

What OCIT is asking the market to do (summary of RFI scope)​

• Inventory and assessment of Azure-hosted assets (apps, VMs, databases, storage, networking).
• Migration planning: mapping services to a target cloud platform, target architecture and landing zones.
• Reconfiguration and rehosting/replatforming as needed so applications run correctly in the chosen destination.
• Data migration and integrity verification, including rollback plans and reconciliation.
• Security, backup and disaster recovery design in the target environment.
• Training, documentation, runbooks and operational handover.
• Test plans that validate functional behavior, performance baselines and RTO/RPO goals.

What we can verify (hard facts)​

• The RFI exists and was publicly reported by Government Technology’s Industry Insider — California on Sept. 19, 2025. The article summarizes the RFI’s in-scope areas and the submission timeline.
• A procurement aggregator captured the solicitation posting (ID 017‑RX1720273) and reproduced key elements including response deadlines and a short description of the migration scope. That record lists OCIT as the issuing agency.
• OCIT’s public materials confirm the department’s size, mission and CIO; county budget documents are available on the county’s budget website and the Auditor‑Controller / Clerk‑Recorder have documented prior cloud activity such as migrations to AWS for particular systems.

Technical considerations: how you actually move off Azure​

1. Discovery and classification​

• Build a complete inventory of Azure resources (VMs, managed services, databases, storage accounts, networking, identity/Entra configurations, monitoring/telemetry flows).
• Classify workloads by criticality, compliance posture, licensing constraints and coupling to Azure-native services (e.g., Azure AD/Entra, Cosmos DB, Azure SQL features, Managed Identities).

2. Target architecture and landing zone design​

• Define the target provider’s landing zones, identity model, network topology and security posture.
• Prepare for federated identity (if remaining on Microsoft Entra) or a new identity architecture — identity is often the hardest dependency to migrate cleanly.

3. Migration pattern per workload​

• Lift-and-shift: VM exports and direct rehosting when application compatibility and licensing permit.
• Replatform: Minor changes to use target cloud managed services (for example, moving from Azure SQL to a managed RDBMS offering).
• Refactor: Application rewrites for cloud-native services (containerization, serverless) — highest cost and longest timeline.
• Data replication/sync and final cutover with reconciliation.

4. Network and connectivity​

• Recreate network topologies, peering and dedicated connectivity (e.g., equivalents to Azure ExpressRoute) — low-latency backhaul and secure private links are often required for integrated services.
• Test failover, disaster recovery and cross-region routing.

5. Security, compliance and continuity​

• Ensure encryption keys and key management strategy migrate or are re-provisioned with secure rollover.
• Revalidate FedRAMP, CJIS, HIPAA or other controls relevant to county workloads; maintain audit trails across migration.
• Run realistic RTO/RPO exercises.

6. Operations and runbooks​

• Rebuild monitoring, alerting and runbooks (new console, telemetry, dashboards).
• Train staff on operational differences and escalations.

Costs, timeframes and procurement realities​

• Inventory and discovery tooling and consulting hours.
• Data egress fees and network transit costs (some providers charge for transferring data out).
• Staff time for testing, remediation and training.
• Licensing changes (some vendor licenses are tied to a cloud or require different models on another provider).
• Temporary dual-running costs while both environments are live for cutover windows.

Vendor lock-in, contracts and legal traps​

• Contract termination rights, data export guarantees and the format of exported data.
• Licensing portability (are current licenses transferable, do they convert to BYOL or license-included models).
• Audit clauses and retrospective billing adjustments (important if CPU/vCPU accounting differs between providers).
• Service-level commitments for migration support (who is responsible if a migration activity causes extended outage).

Strategic options Orange County might be weighing​

• Move to another hyperscaler (AWS, Google Cloud, Oracle Cloud) for parity of managed services and scale.
• Repatriate sensitive workloads to on-premises or colocation for control and predictable costs.
• Implement a multi-cloud architecture where workloads are placed on the most appropriate platform by cost, compliance and capability.
• Adopt a provider-agnostic operating model using containers and infrastructure-as-code to reduce future lock-in risk.

Practical risks specific to a county migration​

• Service disruption risk for public-facing systems (courts, clerk-recorder, public safety interfaces) with real-world consequences.
• Data integrity risk during mass migrations and during the window when active writes occur.
• Identity and access management risk: migrating or federating Entra/Azure AD requires careful mapping or users will lose access.
• Regulatory and continuity risk: public records and legal holds must be preserved with auditable provenance.
• Vendor coordination risk: managing triage across vendor boundaries during incidents can cause time-to-resolution escalation.

How vendors should respond to the RFI (practical advice)​

• A detailed discovery methodology and representative tooling to produce an inventory within a defined SLA.
• A migration roadmap with deliverables and measurable acceptance criteria for each phase.
• A reversibility plan and rollback triggers for each cutover.
• Security and compliance mapping (how controls will be preserved or replaced in the target environment).
• Staffing and knowledge transfer plans, including training materials and runbooks.
• Pricing models that separate professional services, tooling and any estimated transient dual-running costs.

What this means for other cities and counties​

• Vendors will refine “cloud exit” service offerings tailored to public sector procurement requirements.
• Other counties will re-examine their own cloud contracts, export capabilities and contingency clauses.
• Legislative and audit bodies may start requiring clearer exit strategies and data portability guarantees in cloud contracts for public agencies.

Strengths of OCIT’s approach so far​

• The RFI is the right first step: it invites market input rather than pre-committing to a single technical plan, which lowers procurement risk and improves market discipline.
• OCIT shows pragmatic multi-cloud behavior in existing procurements (some AWS usage; Oracle SaaS for finance/HR), suggesting a willingness to match workloads to the best tool rather than a dogmatic single‑vendor stance.
• The RFI’s explicit emphasis on testing, documentation and staff training shows awareness that people and processes matter as much as tooling.

Risks and weaknesses (what to watch for)​

• The RFI summaries do not publicly disclose the county’s desired target environment or the contractual and budgetary constraints that will define feasibility; without that detail, bidders may produce optimistic or unrealistic plans.
• If the county underestimates egress/networking costs, the financials will shift quickly once data transfer volumes are known.
• Identity and vendor-managed services coupling (e.g., platform-provided identity, analytics or database features unique to Azure) may force expensive refactors.
• A political or schedule-driven rush to move critical systems increases the chance of outages or prolonged remediation.

What to expect next (procurement timeline and signals)​

• The RFI question deadline and submission deadline spelled out in the public summaries (Oct. 6 and Nov. 3) suggest the county intends to gather market input quickly and then decide whether to proceed to an RFP or a different procurement vehicle.
• Vendors that bid should expect follow-up engagements such as vendor conferences, capability demonstrations and requests for clarification.
• Watch for attachments in subsequent procurement notices that disclose inventory baselines, performance baselines and regulatory constraints — those documents will materially change bidders’ costing and approach.

Bottom line: a test case for cloud strategy in local government​

Appendix: practical checklist for an exit-focused RFP (vendor and buyer checklist)​

• Inventory: automated discovery, dependency mapping, configuration snapshots.
• Identity: Entra/Azure AD federation, service principals, managed identity mapping plan.
• Data: export formats, encryption key rollover, egress cost modeling.
• Applications: compatibility matrix (Azure-native to target equivalents), refactor vs rehost decisions.
• Network: private connectivity, routing, firewall rules, VPN/ExpressRoute analogs.
• Security & Compliance: FedRAMP, CJIS, HIPAA mapping and evidence of control continuity.
• Operations: monitoring, logging, incident response, runbooks, training.
• Contract: data ownership, export guarantees, liability for migration-caused outages.
• Pilot: clearly scoped POC, rollback criteria, runbook dry-runs.
• Acceptance: functional and performance acceptance criteria, reconciliation scripts.
• Start with a small, reversible pilot.
• Validate identity and access first (it unlocks everything).
• Iterate on automation to reduce human error.
• Hold vendor coordination off-sites; define single unified incident command for cutovers.