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

Orange County’s IT shop has opened a formal conversation about moving major workloads off Microsoft Azure, issuing a Request for Information (RFI) that explicitly asks the market how to migrate applications, virtual machines, storage, databases and networking from Azure to another cloud — a move that, if pursued, would be a rare and consequential “cloud exit” for a large U.S. county.

Background​

Orange County Information Technology (OCIT) published an RFI describing a comprehensive Cloud Services Migration effort: the county seeks vendor input on approaches, tools and costs to transition workloads currently running on Microsoft Azure to an alternative cloud provider. The RFI lists application services, networking configurations, storage, databases and virtual machines as in-scope and frames the engagement around planning, testing, verification, training and security validation. Submission and question deadlines reported in public summaries are: questions due by 4 p.m. PT on Oct. 6 and RFI responses due by 4 p.m. PT on Nov. 3.
OCIT is not new to cloud diversity: county budget documents and recent public records show that some county systems already run on Amazon Web Services and Oracle cloud applications have been adopted for finance/HR modernization, indicating a multi-vendor posture for certain workloads. OCIT’s FY 2025–26 budget and leadership details confirm the scale of the organization and that KC Roestenberg serves as CIO.

---

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

Moving onto a hyperscale cloud like Azure is now routine for government agencies; moving off one is not. Hyperscalers invest heavily in government certifications, compliance programs and integrations that government IT teams rely on — which is exactly what creates vendor lock-in over time. Orange County’s RFI is therefore important for three reasons:

• 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.

Both the RFI text and public summaries highlight the operational scope (apps, VMs, networks, DBs, storage) and a strong emphasis on testing, validation, security and staff training, which tracks with best practices for high-risk migrations.

---

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

The public reporting and procurement notices show OCIT framing the effort as comprehensive, requiring vendors to demonstrate capacity across the lifecycle:

• 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.

The published procurement summary lists the solicitation as Opportunity ID 017‑RX1720273 and signals the agency’s expectation that responses will cover technical approach, timeline and pricing assumptions.

---

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.

Any further claims about the county’s motivations, preferred target cloud provider, internal timeline beyond the RFI deadlines, or contractual terms (pricing models, penalty clauses, data residency constraints) are not visible in public RFI summaries and must be treated as undetermined until the solicitation documents or county statements are released. Those elements are critical to assessing feasibility but were not published in the summaries that appear in open press and bid-aggregation feeds at the time of reporting.

---

Technical considerations: how you actually move off Azure​

Migrating an entire county IT estate from one cloud to another is not a single technical activity — it is a coordinated program made up of multiple projects. The technical workstreams will typically include:

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.

These steps align with established migration playbooks and case studies from government migrations; successful projects usually pilot non-critical workloads first, iterate lessons learned and keep cutovers reversible until confidence is proven.

---

Costs, timeframes and procurement realities​

Moving at this scale is expensive and complex. Typical cost drivers include:

• 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.

Public procurement summaries and bid listings give a rough estimate band for opportunities of this sort; one aggregator estimated a possible range for the listing between $500,000 and $2,000,000, but that figure appeared as an automated estimate and should be treated as illustrative, not contractual. The county’s own OCIT budget sits well into eight figures for FY25–26, but any single migration program could consume a meaningful share of project funds depending on scope.
Timeframes depend on workload complexity. A phased program that pilots and migrates incrementally can take months to years; a wholesale, high-urgency migration can be run in compressed windows but at significantly higher risk and cost.

---

Vendor lock-in, contracts and legal traps​

A core challenge in any cloud exit is disentangling from provider-specific managed services and licensing. Orange County’s RFI specifically contemplates reconfiguring applications and verifying compatibility — an implicit recognition of lock-in risks.
Key legal/commercial items to investigate:

• 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).

Procurement responses should demonstrate clear contractual strategies: escrow of configs, data exportability proofs, and firm SLAs during migration windows. These topics are frequently where migration programs stall or incur unexpected costs.

---

Strategic options Orange County might be weighing​

Based on common industry options and signals from county documents (Oracle adoption for finance/HR; pockets of AWS usage), the county appears to be embracing a hybrid/multi-cloud posture rather than a single-provider lock-in. Possible target strategies include:

• 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.

Each option has trade-offs: moving to another hyperscaler swaps one ecosystem lock-in for another; repatriation increases capital and operational overhead; multi-cloud raises operational complexity but can act as a hedge. Oracle’s press release that Orange County selected Oracle Fusion for finance/HR earlier in 2025 provides evidence the county is already choosing best-of-breed SaaS services where appropriate — a pattern that could shape migration targets.

---

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.

These are not hypothetical concerns; they map directly to lessons learned from government migrations and documented migration playbooks that emphasize pilots, rollback plans and staged approaches.

---

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

For firms planning a response, the county will likely evaluate proposals on technical depth, proven migration experience for similar government customers, security posture and clarity on costs and timelines. A strong response should include:

• 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.

Proposers should also be explicit about their assumptions — especially assumptions about the use of Azure-managed features that may have no direct analog in the target cloud, as these will materially affect cost and duration.

---

What this means for other cities and counties​

If Orange County proceeds beyond an RFI to a formal solicitation and ultimately executes a migration, it will create a public case study on how a large county executes a hyperscaler exit. That could have ripple effects:

• 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.

The public sector has already been experimenting with such choices — the California Department of Technology publishes cloud guidance and FedRAMP frameworks that agencies must consider, and that regulatory context will be central to any county migration decision.

---

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.

Where public reporting lacks detail, those gaps should be considered red flags until the formal solicitation documents — which typically contain technical attachments, performance objectives and compliance requirements — are published.

---

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​

Orange County’s RFI is a significant procurement signal: it shows a large county is actively querying the market on how to leave a hyperscaler while emphasizing testing, security and operational readiness. That public posture is both pragmatic and audacious: pragmatic because it starts with discovery and market input; audacious because it contemplates a large-scale exit that many public agencies avoid precisely because it’s hard.
For vendors, integrators and county IT leaders watching closely, the important takeaways are practical: plan for staggered migrations, prioritize identity and data integrity, cost-evaluate egress and dual-running windows, and put reversibility at the heart of each migration phase. The RFI’s publication is the beginning — not the conclusion — of a complex, high-stakes program that will test Orange County’s technical discipline, procurement rigor and readiness to operate across multiple cloud ecosystems.

---

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.

---

Orange County’s RFI is now a public focal point for the hard question many IT leaders prefer to avoid: how do you undo the cloud when the organization’s business needs, budgets or risk calculus change? The answers will be technical, contractual and organizational — and they will set a useful precedent for other counties and cities that must reconcile modern cloud adoption with long-term portability, resilience and cost predictability.

---

Source: GovTech Orange County Seeks Info on Migrating Off Azure

 

[ChatGPT]

Orange County Information Technology (OCIT) has formally asked the market how to move its data, applications and cloud services off Microsoft Azure — a move framed as a comprehensive “Cloud Services Migration” RFI that would, if executed, amount to a rare large-scale government cloud exit and a consequential technology and procurement undertaking. The notice asks vendors for approaches, tools, timelines, and cost estimates to relocate application services, networking configurations, storage, databases and virtual machines to an alternative cloud provider, and it emphasizes planning, testing, verification, training and security validation as core deliverables.

Background​

Orange County’s RFI appears in public procurement feeds as Opportunity ID 017‑RX1720273 and was reported by industry press in mid‑September 2025; question submissions close on October 6, 2025 and RFI responses are due November 3, 2025. The county’s public procurement notices and aggregator records describe a scope that includes VMs, databases, storage and networking, while also asking vendors to surface realistic timelines, tools and cost models.
OCIT is not new to multi‑vendor cloud activity: county documents and press coverage show earlier migrations away from legacy systems (including retirement of an IBM mainframe in FY 2022–23) and selective use of other cloud vendors such as Amazon Web Services and Oracle for particular workloads. OCIT’s FY 2025–26 program and staffing scale are substantial — the organization’s annual budget and recent SaaS choices provide context for the RFI’s ambition.

---

What the RFI actually asks for​

The RFI frames the migration as a lifecycle program, not a single tactical lift-and-shift sprint. Public summaries and the procurement listing outline the county’s immediate expectations:

• Inventory and assessment of Azure‑hosted assets (applications, VMs, managed services, databases, storage, networking and identity configurations).
• A target architecture and landing zone design in the destination cloud, including identity, networking and security models.
• Migration approaches per workload (lift‑and‑shift, replatform, refactor), with testing, reconciliation and rollback plans.
• Security validation, backup & recovery planning, and compliance mapping (FedRAMP/CJIS/HIPAA or other applicable controls).
• Training, documentation, operational runbooks and a formal handover to county staff.

These elements emphasise that OCIT wants vendor proposals that go beyond tooling — they need program governance, measurable acceptance criteria and operational readiness for county teams.

---

Why this RFI matters: beyond another procurement​

Moving a large public‑sector estate off a hyperscaler is uncommon and strategically significant. Three reasons this RFI is noteworthy:

• It signals a willingness by a major U.S. county to consider vendor diversification and the operational implications of leaving a single hyperscaler. That matters politically (contracting, vendor relations) and technically (lock‑in, interoperability).
• It creates a procurement trail and a market signal that vendors and systems integrators will respond to — leading to new “cloud exit” offerings targeted at public agencies.
• It forces an explicit reckoning with the practical mechanics of a cloud exit: identity, provider‑specific managed services, egress costs, licensing portability, and auditable continuity for public records. These are the issues that typically shape feasibility and cost far more than raw compute pricing.

---

Technical challenges and operational risks​

Migrating an entire local government portfolio of services requires coordinated technical workstreams, each carrying distinct challenges and failure modes.

1. Discovery and dependency mapping​

A full inventory must capture not just VMs and databases, but the dependencies that break assumptions in a new environment: identity bindings, managed services (e.g., Cosmos DB, Azure SQL features), networking peering, private link architectures, monitoring and telemetry pipelines, secrets and key management, and service accounts. Underestimating these dependencies is the single most common root cause of migration overruns.

2. Identity and authentication​

Microsoft Entra ID (formerly Azure AD) is central to many Azure deployments. Federated sign‑on, managed identities, conditional access policies, service principals and token lifecycles are all tightly coupled to Microsoft’s identity stack. Replacing or federating those identities — or maintaining a hybrid identity model — is often the hardest technical and operational part of a migration. Microsoft’s documentation confirms that Azure AD (now Microsoft Entra ID) remains functionally stable but that names and branding have shifted; migration programs should assume identity is a first‑class migration deliverable.

3. Managed‑service feature parity and refactor cost​

Many Azure customers use managed platform services (serverless functions, PaaS databases, analytics, key vaults). Those services rarely map one‑to‑one across hyperscalers. Options are:

• Lift‑and‑shift (VM exports) — lower code change but higher operational friction and potential license mismatches.
• Replatform (migrate to equivalent managed services) — moderate code/config changes and potential integration work.
• Refactor (rewrite for cloud native) — highest cost and longest timeline but best long‑term portability.

Each path has cost, schedule and risk tradeoffs; proper classification and small pilots are essential.

4. Network architecture and connectivity​

Rebuilding private connectivity (the equivalent of Azure ExpressRoute), peering, DNS and routing, and ensuring low‑latency interlinking to on‑premises or other clouds is nontrivial. During dual‑run cutovers, you’ll manage cross‑cloud traffic flows that carry egress costs and potential latency impacts.

5. Data integrity, continuity and legal holds​

Public records, court filings, legal holds and audit trails require provable continuity and immutability during migration. Any data reconciliation failures or incomplete exports can have legal consequences. Agencies must retain auditable provenance and a defensible rollback posture. FedRAMP and other government guidance emphasise customer responsibilities in shared‑security models, which makes documenting control ownership critical during migration.

6. Costs: egress, dual‑running, and licensing​

Data egress and temporary dual‑run environments are major cost drivers. Licensing models that differ by cloud or are tied to specific vendor bundles can materially change OPEX and CAPEX. Public solicitation summaries show each of these concerns explicitly as areas for vendor responses.

---

Costs, estimates and the hard truth about price tags​

Public procurement summaries and bid aggregators offer estimates, but they vary and should be treated as indicative, not contractual.

• One procurement aggregator listed the RFI and produced an automated range; different aggregators show different machine‑generated estimates. These are not the county’s official budget numbers.
• Industry reporting has repeated a $5 million–$15 million band in press summaries; however the underlying aggregator warns that its estimates were generated with AI and are illustrative. That discrepancy matters — a full county‑wide program can run much higher depending on scope, while a narrower portfolio migration could fit a smaller band. Treat any public estimate as uncertain until the final solicitation documents and scope attachments are released.

OCIT’s own organizational budget is substantial; however, program funding must compete with other county priorities and approvals. Any proposer should therefore state assumptions clearly and propose staged, measurable phases to control risk and cost.

---

Strategic options the county (and vendors) will likely evaluate​

The RFI invites market feedback on different target strategies. Practically, there are four broad paths — each with tradeoffs:

• Move to another hyperscaler (AWS, Google Cloud Platform, Oracle Cloud) for managed feature parity and scale. This swaps one ecosystem for another and may preserve some managed service benefits, but it can still create new forms of vendor lock‑in.
• Adopt a multi‑cloud strategy, placing workloads where cost, compliance and functionality fit best. This reduces single‑vendor dependence but raises operational complexity and tooling overhead.
• Repatriate sensitive or compliance‑heavy workloads to on‑premises or colocated data centers to gain control and avoid recurring hyperscaler costs. This increases capital expense and operational burden but offers stronger control over data residency and egress.
• Pursue provider‑agnostic modernization (containers, Kubernetes, IaC, GitOps, service mesh) to reduce future lock‑in risk. This requires investment in refactoring and may pay off over multiple years with greater portability.

Oracle’s announcement about interconnects and Orange County’s selection of Oracle Fusion for finance/HR earlier in 2025 show the county already using multiple clouds and SaaS vendors — evidence it favors best‑of‑breed decisions for specific workloads rather than blanket single‑vendor strategies. That history will shape vendor proposals and the county’s appetite for each option.

---

Procurement, contracts and legal traps to watch​

Large cloud exits often stumble on contractual language and licensing:

• Check termination rights, data export guarantees, and the format in which data can be exported. Vendors must demonstrate export capabilities for all asset types.
• Licensing portability: confirm whether existing licenses are transferable, convert to BYOL, or require renegotiation. Differences in CPU/vCPU accounting across clouds can also change billable units.
• Audit and retrospective billing clauses may surface during migration windows — propose contractual protections (escrowed configs, migration SLAs, indemnities) for the customer.
• For government customers, ensure the destination cloud or architecture meets applicable compliance frameworks (FedRAMP, CJIS, HIPAA). FedRAMP has been evolving its model and guidance in 2024–25, so proposals should explicitly map how controls will be maintained in the target architecture.

---

How strong vendor responses should be structured​

OCIT’s RFI is a market conversation. Respondents that stand out will bring depth, realism and auditability. Recommended structure for proposals:

• Executive summary with clear assumptions and a proposed phased program.
• Discovery methodology and tooling to deliver a complete resource inventory within a defined SLA.
• Migration roadmap split into prioritized waves (pilot → non‑critical → critical), with measurable acceptance criteria for each wave.
• Security, compliance and identity plan mapping every control to FedRAMP/State policy responsibilities.
• Cost model that separates professional services, tooling, egress and dual‑run operational costs.
• Reversibility and rollback plans for every cutover, with defined triggers and KPIs.
• Staffing, knowledge transfer, runbooks, and training schedules for OCIT teams.
• Case studies and three verified government engagements of similar scale and complexity.

Proposers should be explicit about assumptions — especially regarding Azure‑native features that lack direct analogs — because these assumptions materially affect cost and duration.

---

Broader implications for the public sector​

If Orange County proceeds beyond this RFI to a large‑scale migration, the effects could ripple across state and local government procurement and cloud strategies:

• Expect more explicit “exit” planning language in future cloud contracts (data portability, escrow, exit SLAs).
• Vendors will likely refine packaged “cloud exit” offerings for the public sector, blending tooling, compliance artifacts and guaranteed migration SLAs.
• Other counties and municipalities will reassess their cloud contracts and contingency clauses, possibly leading to multi‑vendor or hybrid strategies becoming more common in government IT portfolios.

FedRAMP’s shift toward more machine‑readable authorization packages and trust‑center models also changes the procurement landscape: greater transparency and standardized exportable authorization artifacts can make migrations easier — but only if those tools are adopted and used consistently.

---

Strengths and risks in OCIT’s approach so far​

Strengths

• The RFI is the right first step: it seeks market input and avoids premature technical commitments, which reduces procurement risk and invites more disciplined proposals.
• OCIT’s prior use of multiple cloud providers and adoption of SaaS for finance/HR shows pragmatic, workload‑specific decision making rather than ideological single‑vendor bias.
• The RFI’s emphasis on testing, verification and staff training demonstrates awareness that people and processes are as important as code.

Risks and open questions

• The procurement summaries do not publish OCIT’s desired target environment or detailed contractual constraints — gaps that may lead to optimistic or unrealistic vendor proposals. Until full solicitation documents are released, many important program variables remain unknown.
• Egress and network transit costs can be large and are often underestimated in early planning. These costs can reshape the business case for migration.
• Identity coupling (Microsoft Entra ID), managed service incompatibilities and licensing portability are practical blockers that can force expensive refactors if not handled properly.

---

Practical timetable and staged approach (recommended by best practice)​

A modeled program for a migration of this scope typically includes the following phases and approximate sequencing (subject to the county’s priorities and workload complexity):

• Discovery & classification (4–12 weeks): inventory, dependency mapping, criticality ranking.
• Pilot wave (8–16 weeks): migrate a small set of non‑critical services to validate tools and cutover processes.
• Wave planning & replatforming (3–12 months): execute batch migrations with iterative learnings.
• Critical cutovers & final reconciliation (3–9 months): migrate high‑criticality systems with extended rollback windows and audit validation.
• Post‑migration hardening (3–6 months): decommission old accounts, optimize costs and complete knowledge transfers.

Timeframes will vary widely; total programs for a large county can run from months to multiple years depending on refactor needs and political constraints. The RFI timeline (questions by Oct 6; responses by Nov 3) reflects an early market discovery phase, not an immediate wholesale cutover schedule.

---

Conclusion​

Orange County’s Cloud Services Migration RFI is a significant market signal: a major U.S. county is formally opening the question of leaving Microsoft Azure for selected workloads and asking practitioners for concrete migration approaches, timelines and costs. That signal will catalyze vendor offerings, procurement scrutiny and operational planning across the public sector. The technical and contractual complexity of a cloud exit — identity, managed services, egress, licensing and legal continuity for public records — means successful proposals must be pragmatic, staged and explicit about assumptions.
The RFI is the right first step for OCIT; the real measure of success will be in realistic vendor responses, clear contractual guardrails (especially around data export and continuity), and an incremental migration plan that minimizes disruption while giving county teams the training and documentation they need to operate in the destination environment. Until the county publishes full solicitation documents and the final scope attachments, cost estimates and schedules remain provisional; vendors and observers should treat public estimate bands as illustrative and assume the county will need fully transparent, auditable migration plans to protect critical public services.

---

Source: Data Center Dynamics Californian county publishes RFI to migrate off Microsoft Azure