Services / Cloud Migration Strategy
Cloud migration is one of the most consistently over promised and under-delivered programmes in enterprise technology where organizations migrate expecting cost reduction, agility and modernization.
What they frequently encounter is when cloud bills that exceed on premises costs within 18 months, applications that break in ways the pre migration assessment did not predict, data sovereignty obligations that were not understood until after the migration and a security posture that is worse in the cloud than it was on premises because the shared responsibility model was not correctly implemented.
The 31% average cloud waste figure that the industry consistently reports is not waste from incompetent organizations but it is the structural consequence of migrating before the strategy is right before workloads are correctly classified, before cost governance is in place, before the data residency constraints are mapped, before the application dependencies are fully understood.
Organizations that do not address these structural questions before migration embed the answers to them is incorrectly into the cloud architecture and then spend years trying to correct them at higher cost than getting them right would have required at the start.
This engagement produces a cloud migration strategy that is grounded in what your infrastructure actually is what your regulatory obligations actually require and what your team can actually execute and not in what a vendor’s reference architecture says your organization should look like.
The strategy phase is fixed price and precedes any migration execution and where migration execution is out of scope and is carried out by your team or an infrastructure partner from the strategy and specifications we produce.
Price Range
£22,000 to £180,000+
Strategy and specification only. Migration execution is separate and additional are typically 3 to 20× the strategy fee.
Strategy and specification only. Migration execution is separate and additional are typically 3 to 20× the strategy fee.
Duration
8 weeks to 6 months
Strategy phase only. Migration execution timeline depends on workload count, complexity and your team’s capacity which is entirely outside our control.
Strategy phase only. Migration execution timeline depends on workload count, complexity and your team’s capacity which is entirely outside our control.
Scope boundary
We produce the strategy, workload assessments, architecture design, migration runbooks and FinOps framework. We do not execute migrations, configure cloud environments or procure cloud services.
Platforms
AWS · Microsoft Azure · Google Cloud · Hybrid · Multi cloud · UK Sovereign Cloud (G Cloud 14)
Frameworks
UK GDPR · DORA · NIS2 · NHS DSPT · GovAssure · ISO 27001 · G Cloud 14 · PSN · PCI DSS
Contract
Fixed price strategy phase. 50% on signing, 50% on delivery acceptance. Migration oversight (if required) priced separately.
Strategy ≠ executionThis engagement produces specifications your team or an infrastructure partner executes. The total cost of migration and cloud provider fees, implementation labor, license changes, network connectivity which is entirely separate from and additional to this fee. At enterprise scale, that total cost commonly reaches £5M to £20M. The strategy fee is the cost of not making expensive mistakes at that scale.
Why Cloud Migrations Fail
The specific failure modes where each one preventable which none of them are rare.
These are not theoretical risks but they are the documented causes of the 65% failure rate in digital transformation programmes and the 31% average cloud waste figure where every one of them has a structural cause and a structural prevention which the prevention requires work before migration begins and which is exactly when most organizations are least inclined to invest time and money in strategy rather than execution.
01
Cloud costs exceed on-premises costs within 18 months
The business case for migration was built on headline cloud pricing applied to current resource consumption. It did not account for egress costs (paying to move data out of the cloud), reserved instance underutilization when demand forecasts are wrong, licensing cost changes when on premises licenses do not transfer to cloud, the operational cost of managing cloud environments and the tendency of cloud provisioning to expand beyond initial scope because provisioning is frictionless.
Seen in
Organization migrates a 40 server on premises environment with an annual infrastructure cost of £280,000. First cloud bill is £38,000 per month. Annualized from £456,000 which is 63% above the on premises baseline they migrated to escape.
Structural prevention
Total cost of ownership modelling per workload before migration including egress, licensing changes, operational overhead and a 20% contingency for demand variance. FinOps governance framework in place before the first workload moves with tagging taxonomy, cost allocation by team and workload, automated right sizing alerts, commitment discount planning. Budget ceiling per environment with automated enforcement.
02
Applications break in cloud that worked on premises
On premises applications develop dependencies that are invisible until the environment changes with hardcoded IP addresses, network latency assumptions built into timeout configurations, local file system paths that do not exist in cloud, Active Directory integrations that rely on network proximity and Windows licensing tied to specific hardware. Lift and shift migration and moving VMs without modification which preserves all of these dependencies in a new environment where they no longer work.
Seen in
ERP system migrated successfully at the VM level. Failed to start because a hardcoded reference to the on premises file server that hosted configuration files now resolved to an unreachable address. Discovery time of 6 hours during business hours. Root cause identification with 4 additional hours. Resolution with configuration file relocated, 2 hours. Total disruption of 12 hours. This was in the dependency assessment for any experienced pre migration analyst to find.
Structural prevention
Dependency mapping at application layer and not just infrastructure layer which is before classification. Every dependency with network paths, authentication integrations, file system references, hardcoded IPs, timeout configurations, licensing integrations. Applications classified for migration approach based on what the dependency map reveals, not on application age or business priority alone.
03
Data sovereignty obligations discovered after migration
Data residency requirements under UK GDPR, sector specific regulations and contractual obligations with clients or partners are not always systematically reviewed before cloud selection. A default cloud provider selection (typically AWS us east 1 or Azure West US because those are where most tutorial deployments point) places data outside UK jurisdiction. For NHS data, financial services data and government data, this may constitute a regulatory breach which is discovered during audit, not during migration planning.
Seen in
NHS connected digital health company migrates to AWS. Post migration audit reveals that NHS patient data is stored in EU West 1 (Ireland). NHS DSPT requires data to remain in the UK. Full re migration to UK region required. Cost of remediation from £180,000 in additional migration work plus 3 month delay to a product launch.
Structural prevention
Data classification and residency mapping before any cloud selection. Every data type with its regulatory classification, the jurisdiction it must remain in, the contractual obligations affecting it and the cloud provider regions that satisfy those obligations. Cloud provider selection made after data residency requirements are mapped and not before. For NHS, government and financial services with UK sovereign cloud regions identified and validated as compliant before architecture is finalized.
04
Security posture degrades after migration
The cloud shared responsibility model means the cloud provider secures the infrastructure; the customer is responsible for everything above it — operating system, application, data, identity, network configuration and access controls. Organizations that migrated from on-premises environments where firewalls, network segmentation, and access controls were managed by the infrastructure team arrive in cloud environments where those controls must be deliberately configured — and if they are not, the default configuration is frequently permissive in ways that on premises environments were not.
Seen in
Organization migrates database server to cloud. On premises with database accessible only from the application server via VLAN segmentation, enforced by physical network. In cloud with database security group left at default configuration during migration pressure which is accessible from any IP on port 3306. This misconfiguration existed for 47 days before detection. During that period once one confirmed external scan attempt and one successful authentication attempt from an unrecognized IP.
Structural prevention
Security posture design as an integrated component of the migration architecture which is not a post migration hardening exercise. Every workload where the security controls required in cloud, the default cloud configuration and why it is insufficient and the specific configuration changes required before the workload goes live. Cloud security baseline standards enforced via policy as code before any workload is migrated. Configuration drift monitoring active from day one of cloud operation.
05
Migration waves planned by convenience rather than dependency
Migration waves are often planned around team availability, vendor contract expiry dates or organizational politics and not around application dependency chains. Migrating an application before the database it depends on is in the cloud creates a hybrid dependency that performs poorly and creates a split that must eventually be resolved. Migrating a front end application before the authentication service creates an interim period where the security architecture is genuinely weaker than either pure state.
Seen in
Wave 1 migrations selected by the department heads most willing to volunteer their applications. Result is 14 applications migrated in wave 1 of which 9 had dependencies on systems remaining on premises. Performance of migrated applications are degraded due to WAN latency on every on premises dependency call. Unexpected WAN egress cost from £12,000 per month. All 9 required re sequencing into later waves, effectively duplicating the migration work.
Structural prevention
Migration wave sequencing derived from the dependency graph, not from organizational convenience. Dependencies migrated before the systems that depend on them. Applications with shared dependencies grouped into the same wave. Where a dependency cannot be migrated in the required sequence, the architectural solution which is when the API gateway, data replication, interim caching is designed and costed before the wave plan is finalized.
06
Lift and shift applied to workloads that required re architecture
Lift and shift (moving a VM as is to cloud) is appropriate for some workloads and catastrophically wrong for others. A stateful monolithic application that was designed for on premises vertical scaling cannot take advantage of cloud elasticity and will cost more in cloud than on premises because cloud pricing assumes horizontal scaling and cloud native design. Organizations that lift and shift everything to meet a migration deadline with the intention of re architecting later, rarely re architect. The temporary architecture becomes permanent.
Seen in
Organization lifts and shifts 80 application servers. 12 of them are monolithic applications with no horizontal scaling capability. In cloud, they occupy oversized reserved instances to guarantee capacity because cloud elasticity does not apply to them. Annual cost of these 12 workloads in cloud from £340,000. Equivalent on premises cost from £95,000. “Temporary” lift and shift from 4 years and counting.
Structural prevention
Every workload classified using the correct migration approach before wave planning begins. Four approaches assessed per workload: Lift-and-Shift (justified only where the workload is cloud cost neutral and will be retired within 24 months), Re Platform (appropriate for most workloads with minimal code change, significant cloud cost benefit), Refactor (justified where cloud native elasticity delivers measurable ROI over the application lifetime) or Replace/Retire (workloads that should not be migrated because they should not exist). Classification drives sequencing, cost modelling, and architecture approach.
07
No rollback plan. Migration cannot be reversed when it fails.
Migration runbooks are written for the success path. The rollback path and what to do if the migrated application does not work correctly and needs to be reverted to on premises which is either not documented, not tested or impossible to execute because on premises infrastructure was decommissioned before the cloud migration was validated. A migration that cannot be rolled back is not a migration and it is a forced cutover.
Seen in
Core HR application migrated on a Friday evening. Application fails validation Saturday morning: data was migrated but the payroll integration does not function. Rollback plan with return the VMs to on premises. Problem is the on premises hypervisor host was decommissioned on Friday afternoon to free up hardware for a new purchase. Monday morning payroll run under manual processing for 2,400 employees. Tuesday an emergency procurement of temporary on premises hardware. Total cost including contractor time from £85,000. Payroll error corrections with 3 weeks of HR time.
Structural prevention
Every workload migration runbook includes the success validation criteria, failure criteria, rollback procedure and rollback validation. On premises infrastructure is not decommissioned until the cloud migration has operated successfully for a defined parallel run period with minimum 2 weeks for non critical workloads, minimum 4 weeks for critical workloads. Parallel run exit criteria are defined before migration begins, not after the cloud environment has been live for a month and someone wants to shut down the on premises hardware.
08
The team cannot operate what was built
Cloud infrastructure is fundamentally different from on-premises infrastructure in its management model. An IT team that has spent years managing VMware, Windows Server and on premises networking needs substantial retraining and adjustment time to manage AWS EC2, Azure Resource Manager and cloud networking. Migration programmes that deliver a cloud environment to a team unprepared to operate it create a risk exposure that is worse than the pre migration state which is more complex infrastructure, managed by people whose skills do not yet match the environment.
Seen in
Organization migrates successfully to Azure. 3 months post migration with a routine certificate renewal that previously took 30 minutes on premises takes 4 hours because no one on the team understands Azure Key Vault. A security group change that previously required a firewall rule change now requires understanding of NSGs, Application Security Groups, and Azure Policy which three concepts the team has not yet encountered. Time to resolve routine operational tasks with 3 to 8× on-premises equivalent for 6 months.
Structural prevention
Skills gap assessment as a mandatory component of migration strategy. Every operational task the team currently performs on premises under its cloud equivalent, the skills required and the gap between current team capability and required capability. Training programme designed and resourced before migration begins. Runbooks written to the capability level of the team that will execute them and not the capability level of the team that designed the migration. Operational handover period with design team support explicitly included in the migration timeline.
09
Licensing costs were not modelled before migration
Software licensing in cloud is materially different from on premises. SQL Server licenses do not transfer to cloud without significant cost change. Windows Server Datacenter Edition licenses which cover unlimited VMs on premises, cover a limited number of cloud VMs depending on the provider’s licensing model. Oracle database licenses in cloud are notoriously expensive and frequently require more licenses in cloud than on-premises for the same workload due to Oracle’s vCPU counting methodology. These costs are invisible until the first invoice.
Seen in
Organization migrates Oracle database to AWS RDS. Oracle licenses on premises which are covered by existing perpetual license with annual support. Oracle licenses in AWS with Oracle charges based on vCPU count in the cloud environment. AWS instance sizing required for the workload with 32 vCPUs. Oracle cloud license cost from £180,000 per year. On premises licensing is already paid. Net additional annual licensing cost from migration from £180,000. This was knowable before migration and was not modelled.
Structural prevention
Licensing audit before migration with every software product deployed across every workload, its current license terms, the cloud equivalent license terms from each candidate cloud provider and the cost differential. Oracle, Microsoft, SAP and Citrix receive specific attention because their cloud licensing terms are consistently surprising. Where licensing costs make a workload cloud uneconomic, Re Platform to an open source or cloud native alternative is assessed as the alternative migration approach.
Workload Classification Framework
Four migration approaches with the correct one per workload is determined by analysis and not by schedule pressure.
The most consequential decision in cloud migration strategy is which approach to use for each workload where most organizations default to Lift and Shift because it is fastest and requires no application changes, this is the correct decision for a minority of workloads and an expensive decision for the majority where every workload in scope is assessed against the four approaches below which the assessment output is a classification with documented justification and not a recommendation without reasoning an in which the justification is what allows the decision to survive the commercial pressure to accelerate migration and choose the fastest option for every workload.
Approach A
Lift and Shift (Rehost)
Move the workload to cloud with no modification. The VM is copied or exported to cloud compute. Application code, configuration and dependencies are unchanged. The cloud environment replicates the on premises environment as closely as possible.
Justified when
The workload will be retired within 18 to 24 months, making re architecture investment unrecoverable. The workload has complex licensing or integration dependencies that make modification high risk. The on premises hardware contract is expiring and the workload must move to avoid a hardware refresh cost but the application is approaching end of life. The migration is a datacenter exit, not a cloud first strategy.
Wrong when
The workload is expected to remain in production for 3+ years because lift and shift locks in on premises architecture that will cost more in cloud than alternatives. The workload has horizontal scaling requirements that cloud could satisfy but the current architecture cannot. The workload is stateful in ways that make cloud pricing unfavorable.
Cost implication
Typically 80 to 120% of on premises cost in cloud. Sometimes more, rarely less. The “cloud is cheaper” assumption does not hold for lift and shift workloads.
Approach B
Re Platform (Lift Tinker Shift)
Migrate with targeted modifications that enable cloud benefits without full re architecture. Change the database from self managed to managed cloud service. Move from on premises load balancer to cloud load balancer. Containerize the application without changing the application code. The application logic remains unchanged; the infrastructure layer adopts cloud native components.
Justified when
The application will remain in production for 3+ years. The infrastructure components (database, load balancer, caching layer) are significant maintenance overhead that managed cloud equivalents would reduce. The application logic is stable and the risk of modification is low. The cloud cost reduction from managed services justifies the re platforming effort.
Wrong when
The application will be replaced entirely within 18 months where re platforming investment is unrecoverable. The application has so many infrastructure dependencies that re platforming requires application code changes, at which point Refactor should be assessed. The team lacks the skills to operate the target managed cloud services.
Cost implication
Typically 50 to 75% of on premises cost in cloud over a 3 year horizon, once managed service efficiency is factored in. Higher upfront migration cost than Lift and Shift; lower ongoing cost.
Approach C
Refactor (Re-architect)
Rebuild the application to be cloud native with stateless where possible, horizontally scalable, using cloud services (queues, event streams, functions, container orchestration) that were not available on premises. The application code changes substantially. The architecture changes fundamentally. The result is an application that can exploit cloud elasticity in a way that on premises applications cannot.
Justified when
The application has highly variable demand where cloud elasticity delivers significant cost reduction. The application will remain in production for 5+ years, making the re architecture investment recoverable. The current architecture has become a bottleneck to business capability and where new features take months to release because the monolith is complex to modify. The development team has the capability to execute a re-architecture programme alongside normal delivery.
Wrong when
The development team does not have cloud native development skills and cannot acquire them within the migration timeline. The application has stable, predictable load where elasticity provides no cost benefit. The business does not have the tolerance for the delivery slowdown during a re-architecture programme. The application will be replaced within 3 years which ROI period is too short.
Cost implication
Highest upfront cost (development effort). Lowest long-term cloud infrastructure cost. Typically 30 to 50% of on premises cost in cloud over 5 years. Requires accurate demand forecasting to justify high elasticity benefit only materializes if demand actually varies significantly.
Approach D
Replace and Retire
Do not migrate. Either retire the workload (it should not exist but it is serving a function that nothing in the business actually needs any more) or replace it with a SaaS product (the application is not differentiated and a commercial product delivers the same capability at lower total cost). Both outcomes eliminate the workload from the migration programme.
Justified when
The workload has no measurable business users (common portfolios consistently include applications that no one uses). The function is available in a SaaS product at lower total cost than migration and ongoing operation. The application is a legacy system whose function has been superseded by a newer system that is already in use where the legacy system is running only because no one turned it off.
Wrong when
The SaaS replacement requires significant integration work that negates the cost saving. The application contains business logic that is not available in any commercial product and would need to be rebuilt. Data migration from the legacy system to the replacement is complex enough to constitute a significant programme in its own right.
Cost implication
Zero cloud migration cost. Elimination of ongoing on premises operational cost. SaaS subscription cost if replacing rather than retiring. In most estate assessments, 15 to 25% of workloads are candidates for Replace and Retire which is eliminating them from the migration scope significantly reduces programme cost and risk.
What determines the correct approach is the workload assessment which is not the migration schedule. A programme that classifies all workloads as Lift and Shift to accelerate the migration timeline is making an economic decision with consequences that will play out over 3 to 5 years of cloud operation. Those consequences are quantifiable before the decision is made. We quantify them. The client makes an informed decision. If the client chooses a faster approach after seeing the cost comparison, that is their choice and documented with the cost implication on record.
Engagement Tiers Scope, Price and Timeline
The three tiers strategy and specification only and where migration execution is always separate.
All three tiers produce strategy, workload assessments, migration runbooks, architecture specifications and FinOps framework which is not implementation and where the strategy phase is with a fixed price and where migration execution, carried out by your team or an infrastructure partner is a separate engagement that follows, we are available as migration oversight advisors during execution which is priced as a day rate retainer, not included in the strategy fee and the total cost of migration including execution is typically 3 to 20× the strategy fee depending on estate size.
Focused Strategy
Focused Migration Strategy
For organizations with up to 30 workloads, a single on premises site, one cloud destination, no OT or specialized industrial systems and one regulatory framework. Typical are SMEs, single site professional services firms, independent schools, small healthcare providers, small charities. If you have more than 30 workloads or regulatory obligations in more than one framework, the Professional tier is more appropriate.
£22,000
Strategy only · fixed · VAT excl.
8 weeksAssumes full client cooperation throughout. Delays extend proportionally.
Assessment & Classification
Current estate inventory with up to 30 workloads documented
Application dependency mapping with all 30 workloads, including undocumented dependencies
Licensing audit is for all software across all 30 workloads, cloud licensing cost comparison
Data classification with regulatory category per data type, residency requirements per dataset
Migration approach classification with A/B/C/D per workload with documented justification
Skills gap assessment with team capability vs requirements of target cloud environment
One regulatory framework compliance mapping
Multi cloud assessment (single destination cloud only)
OT and industrial system assessment
Strategy & Architecture
Cloud provider selection with assessment and recommendation for single destination
Target architecture design with network topology, identity, security posture, landing zone
Total cost of ownership model with 3 year cost projection per workload in cloud vs on premises, including licensing, egress, operational overhead
Migration wave plan with sequenced by dependency graph, not by organizational convenience. Up to 4 waves.
FinOps framework with tagging taxonomy, cost allocation design, budget alerts, right sizing baseline
Security posture design with shared responsibility model mapping, security controls per workload, baseline configuration standards
On-premises decommission plan with what gets turned off when, parallel run periods per workload
Multi cloud architecture
Runbooks & Specifications
Migration runbooks for all workloads with success path, validation criteria, failure criteria, rollback procedure
Landing zone specification with implementation ready document your team or partner builds from
FinOps implementation specification with exact configuration steps for cost governance tools
Security baseline specification with exact configuration for all security controls required pre-migration
Post migration validation checklist per workload
Training needs list with specific cloud skills required per role, recommended training resources per gap
Regulatory evidence pack for selected framework
Migration execution oversight (available as day rate retainer from £1,900 per day)
Timeline — 8 Weeks (full client cooperation assumed throughout)
Wk 1
Estate Inventory
Document all 30 workloads. IT lead interviews. Access to infrastructure documentation.
Common issue: estate inventory is incomplete or inaccurate. Investigation consistently reveals workloads not in the initial list. Each discovery adds to scope.
Wk 2
Dependency & Licensing Audit
Application dependency mapping. Software licence audit across all workloads.
Licensing audit requires access to software asset management records, purchase orders, and vendor portals. Missing records delay the audit.
Wk 3
Data Classification
Data type inventory. Regulatory classification. Residency requirements. Cloud region constraints.
Data classification requires input from whoever has regulatory compliance accountability. If this person is not identified before week 3, the stage is delayed.
Wk 4
Workload Classification & TCO
A/B/C/D classification per workload. 3 year TCO model. Cost comparison. Board briefing.
TCO model requires accurate current cost data: hardware depreciation, power, cooling, licence costs. If this data is not available, cost model carries explicit uncertainty.
Wk 5 to 6
Architecture & Strategy
Cloud provider selection. Target architecture. Wave plan. FinOps framework. Security posture design.
Board strategy approval required before runbooks are written. If board cycle is monthly, build 3–4 weeks buffer here.
Wk 7 to 8
Runbooks & Handover
All migration runbooks. Landing zone specification. Implementation specifications. IT team review session.
Runbook review by IT team commonly produces questions that reveal gaps in the specifications. Allow 3 business days Q&A after delivery before engagement closes.
What Your Team Must Provide
IT lead with 12 to 18 hours across weeks 1 to 4 for estate inventory, dependency mapping and licensing audit support
Whoever holds regulatory compliance accountability with available for 3 hours in week 3 for data classification input
Access to with infrastructure documentation, software asset management records, vendor contracts, current IT cost data, cloud billing if any cloud already exists
Senior management with available for TCO briefing in week 4 and strategy approval in week 5 to 6
Document reviews returned within 5 business days of issue
Honest disclosure of current estate state including workloads that are undocumented, unsupported or whose owners are unknown
What Is Not in This Engagement
Migration execution with all implementation by your team or partner, entirely separate and additional. Typical cost for 30 workload estate from £80,000 to £300,000 in implementation labor plus cloud provider setup costs
Cloud provider costs during and after migration which is entirely separate from this fee. First year cloud infrastructure costs for a 30 workload estate are typically £25,000 to £120,000 per year
More than one regulatory framework compliance mapping and second framework from £6,000 additional
Post-migration FinOps optimization review at 90 days (available separately from £6,500)
Migration execution oversight with available at £1,900 per day during execution phase
Workloads above 30 with scope addition at £950 per workload
Professional Strategy
Professional Migration Strategy
For organizations with 30 to 150 workloads, up to 4 on premises sites, up to 2 cloud destinations (hybrid or multi cloud) and up to 3 concurrent regulatory frameworks. Typically are NHS Trusts, mid size financial services firms, multi site manufacturers, universities, local authorities, housing associations. Includes healthcare and financial services sovereign cloud requirements where applicable.
£68,000
Strategy only · fixed · VAT excl.
16 weeksMulti site assessment and board cycle typically extend this. Allow 20 to 22 weeks in complex organizations.
Assessment & Classification
Estate inventory is up to 150 workloads across all sites
Application dependency mapping is for all 150 workloads including cross site dependencies
Full licensing audit with all software, all sites, cloud equivalents per provider
Data classification with all data types, all regulatory frameworks, all residency constraints
Workload classification A/B/C/D per workload with documented justification
Multi cloud assessment is up to 2 destination clouds evaluated and compared per workload where applicable
Skills gap assessment across IT team and key business users
Up to 3 regulatory frameworks compliance mapping simultaneously
UK Sovereign Cloud assessment for healthcare and government workloads where required
Strategy & Architecture
Multi cloud architecture where applicable with workload placement per cloud, data flow between clouds, identity federation
3 year TCO per workload with all costs modelled including egress, licensing changes, operational overhead per cloud
Migration wave plan with up to 8 waves, dependency sequenced with detailed inter wave transition management
Full FinOps framework with tagging taxonomy, showback and chargeback model, waste alerting, commitment planning, anomaly detection
Security posture design with cloud security baseline, CSPM configuration, identity architecture, network segmentation
Hybrid connectivity design where on premises systems must integrate with cloud during and after migration
Training programme specification per role with specific skills gaps, recommended training, timeline for capability acquisition
Board ready business case with TCO comparison, risk assessment, programme cost, timeline, success criteria
Runbooks & Specifications
Migration runbooks with all workloads. Success path, validation criteria, failure criteria, rollback for all.
Landing zone specifications per cloud provider, implementation ready
Network architecture specification with hybrid connectivity, cloud networking, DNS, BGP where applicable
FinOps implementation specification with detailed configuration for all cost governance tools and processes
Security controls specification with exact configuration per workload type, policy-as-code templates
Post-migration validation criteria per workload
Compliance evidence pack with all 3 frameworks in submission ready format
90 day post migration FinOps review included (within 3 months of primary migration completion)
Timeline — 16 Weeks Baseline (expect 20 to 22 weeks in practice for multi site organizations)
Wk 1–3
Multi-Site Estate Inventory
All sites, all workloads. IT interviews at each site. Access provisioning across all environments.
Multi site access provisioning is the most common cause of early delay. IT contacts at each site must be identified and briefed before week 1. Provision access before engagement begins.
Wk 4 to 6
Dependency, Licensing, Data
Full dependency mapping, licensing audit, data classification across all sites and all frameworks.
Data classification with 3 frameworks requires legal/compliance input that moves slower than IT input. Identify the data classification lead before week 4 and confirm availability.
Wk 7 to 9
Workload Classification & TCO
A/B/C/D classification for 150 workloads. Full 3 year TCO model. Multi cloud cost comparison where applicable.
TCO model for 150 workloads requires granular cost data. Organizations without a functioning CMDB will need to source cost data from multiple systems and allow additional 1 week.
Wk 10 to 12
Architecture & Strategy
Full cloud architecture, wave plan, FinOps, security posture. Business case document. Board presentation.
Board approval needed before runbook production begins. Monthly board cycles mean this stage can extend by 3 to 5 weeks in organisations without a standing technology committee.
Wk 13 to 15
Runbooks & Specifications
All migration runbooks for 150 workloads. All implementation specifications. Compliance evidence packs.
150 runbooks take longer to review than clients anticipate. Structure the review as wave-by-wave, not all at once. Each wave’s runbooks reviewed and approved before the next set is issued.
Wk 16
Handover
Final deliverables. IT team and infrastructure partner walkthrough. Q&A session. 30 day support window opens.
If an infrastructure partner has been engaged for execution, they should attend the handover session. Executing from strategy documentation without attending the handover creates avoidable misunderstandings.
What Your Team Must Provide
IT lead at each site of 8 to 12 hours per site across weeks 1 to 6 for estate inventory and dependency mapping
Legal compliance representative available for 6 hours in weeks 4 to 6 for data classification across all frameworks
Finance with current IT infrastructure cost data, hardware, power, cooling, license costs per workload or per site
Board sponsor available for TCO briefing in week 9 and strategy approval in weeks 10 to 12
Infrastructure partner (if engaged) is identified before week 13 and available to attend handover
Document reviews with wave by wave review of runbooks, 5 business days per wave
What Is Not in This Engagement
Migration execution with all implementation separate and additional. 150 workload migration implementation are typically £400,000 to £2M in labor depending on approach mix
Cloud provider costs during and after migration: first year cloud costs for 150 workload estate typically £120,000 to £600,000 per year
More than 150 workloads with scope addition at £900 per workload above ceiling
More than 2 cloud destinations or more than 3 regulatory frameworks: scope addition
OT and industrial system migration strategy which requires Enterprise tier
Migration execution oversight is available at £1,900 per day during execution
Enterprise Strategy
Enterprise Migration Strategy
For organizations above 150 workloads, more than 4 sites, OT and industrial systems in scope, post acquisition migration integration, multi-jurisdiction data residency or G Cloud and PSN requirements for government. Also appropriate for organizations that have a failed or stalled migration that requires strategic reset before resumption. All enterprise engagements individually scoped. The price below is a starting point.
From £140,000
Individually scoped · fixed · VAT excl.
From 5 monthsComplex enterprise strategy programmes commonly run 6 to 9 months before migration execution begins.
What Enterprise Adds
No ceiling on workloads or sites
OT and industrial system migration strategy using passive assessment methods
Multi jurisdiction data residency with mapping across UK, EU, US and other relevant jurisdictions with legal team input
Post-acquisition estate integration where migration includes inherited infrastructure from an acquisition
G Cloud 14 procurement framework alignment for public sector organisations
PSN compliance maintained throughout migration for government organisations
All applicable regulatory frameworks have no cap
Failed migration rescue with assessment of where a stalled programme went wrong and redesign of the strategy before resumption
Why Enterprise Takes Longer
OT system assessment using passive only methods is slow by design and with active scanning risks operational disruption
Multi jurisdiction legal review of data residency moves on legal team timescales, not IT timescales
G Cloud procurement requires commercial approval processes that typically run 6 to 12 weeks beyond technical assessment completion
Post acquisition estate integration requires access to systems that may not yet be fully under the acquirer’s control which contractual access arrangements take time
Board approval cycles at enterprise scale where strategy requires sign off at multiple levels before runbook production begins
Enterprise TCO modelling with full licensing audit for 200+ workloads are 6 to 8 weeks of data collection alone
Enterprise Obligations
Named CTO and CIO as programme sponsor with budget authority and board access
Dedicated internal programme coordinator across all sites
Legal team available for multi jurisdiction data residency review which is typically the longest lead resource in enterprise cloud strategy
OT team involvement and approval for any OT system assessment activities before they begin
Infrastructure partner identified and contracted before handover with enterprise migrations require a specialist implementation partner
Quarterly steering committee meetings throughout strategy programme
Bilateral Obligations
What both parties commit to. What follows if either fails.
Client Obligations
Disclose the complete estate including the undocumented parts
Every workload that exists must be in the assessment scope, including systems that are undocumented, running on end of life platforms, owned by people who have left the organization or that no one is certain anyone uses. The workloads most likely to cause migration problems are the ones that are unknown to IT governance. If they are not in the assessment, the strategy will not account for them. When they appear during execution and they will become either out of scope incidents or scope additions at cost.
If undisclosed workloads appear during the engagementAssessed immediately. If they fall within the scope ceiling, incorporated at no additional cost. If they exceed the scope ceiling, treated as scope additions which is costed and agreed before inclusion.
Do not begin migration execution before strategy is complete
Once the strategy engagement begins, migration execution should not proceed on any workload in scope until the wave plan and runbooks for that workload are delivered and reviewed. Executing migration while strategy is in progress creates race conditions with infrastructure changes during assessment invalidate findings, and migrations executed without the approved strategy may contradict the architecture being designed. If business pressure forces migration of a specific workload before strategy completion, notify us as we will prioritize that workload’s assessment and runbook production.
If migration execution proceeds before strategy deliveryThe strategy cannot account for infrastructure that has already changed. Workloads already migrated before the strategy are excluded from the migration wave plan and may require remediation if the migration approach contradicts the strategy’s architecture.
Execute migration using the runbooks as written
Migration runbooks are written for specific reasons and the validation criteria catch specific failure modes, the rollback procedures address specific failure conditions, the parallel-run periods allow specific validations that cannot be done during cutover. Deviating from the runbook which is skipping validation steps because they seem redundant, shortening parallel run periods to accelerate the schedule, eliminating rollback steps because the cutover went smoothly which is how migrations that started well end badly. We are available at day rate for execution advisory if the team encounters situations the runbook does not cover.
If execution deviates from the runbook and a failure resultsWe assess the deviation and the failure. If the failure would not have occurred had the runbook been followed, remediation is not within our scope. If the failure would have occurred even following the runbook, we treat it as a runbook gap and remediate it.
Implement FinOps governance before the first workload migrates
Cloud cost governance cannot be retrofitted after cost has accumulated. The tagging taxonomy, budget alerts, cost allocation structure and anomaly detection must be in place before the first production workload migrates to cloud. The specification for all of these is a deliverable of this engagement. Their implementation is the client’s obligation, in the sequence specified with FinOps first, migration second. The single most predictable cause of unexpected cloud cost is FinOps governance that was planned but implemented too late.
If FinOps governance is not implemented before migrationWe will not sign off the migration readiness checklist for any wave whose cloud environment does not have the FinOps baseline in place. If migration proceeds without our readiness sign off and costs exceed projections, the absence of FinOps governance is the documented root cause.
RJV Obligations
TCO models that include all costs, not just the favorable ones
Total cost of ownership models produced in this engagement include: cloud provider infrastructure costs, egress costs, licensing cost changes (including unfavorable changes for Oracle, Microsoft, and SAP), operational overhead of cloud management, training cost to close skills gaps and a 20% variance contingency on cloud costs to account for demand uncertainty. We do not produce TCO models that omit costs that would make the migration business case less favorable. If the full TCO makes a specific workload cloud-uneconomic, the model says so and we recommend the appropriate alternative approach.
If we omit a cost category from the TCO modelYou have the right to request the full cost model inputs. We will identify and correct any omission within 5 business days. If the omission materially changes a workload classification or a programme cost projection, we revise the affected documents at no additional cost.
Workload classifications justified and revisable
Every workload’s migration approach classification (A/B/C/D) is documented with explicit justification with the dependency analysis that produced the classification, the licensing implications, the TCO comparison across approaches and the criteria that would change the classification. If you dispute a classification because you have information about the workload’s future that changes the analysis and raise it with the documented justification and we will review. We will either revise the classification or explain why the additional information does not change it.
If a classification is later found to be wrong due to our analytical errorWe revise the classification, the affected runbooks, the affected wave plan entries, and the TCO at no additional cost. If the error is discovered during execution and has already caused migration work to be done on the wrong approach, we assess the remediation options and their cost impact.
Runbooks validated before delivery which is not written and handed over
Before delivery, every migration runbook is internally reviewed for completeness are all dependencies in the runbook? Are all validation criteria specific enough to be executable? Does the rollback procedure work given the infrastructure state at the point of failure? Are the parallel run exit criteria measurable? We do not deliver runbooks that we have not reviewed for executability. The internal review standard is where could someone execute this runbook without asking any questions? If the answer is no, it is not ready to deliver.
If a delivered runbook is found to be incompleteRaise within 10 business days of delivery. We review and revise within 5 business days of your report. Revisions discovered during execution that would have been caught by a more thorough pre delivery review are remediated at our cost.
Honest assessment including recommending against migration for specific workloads
If the assessment produces a finding that a specific workload should not be migrated to cloud because the TCO is unfavorable because the licensing cost is prohibitive because the application’s architecture makes cloud operation more expensive than on premises or because the application is approaching end of life which we will say so. We will not classify a workload as migratable to fill wave plans or justify the migration programme’s scale. The Replace and Retire classification exists because it is the right answer for a material fraction of workloads in every estate we have assessed.
If the programme scope changes as a result of Replace and Retire classificationsFewer workloads migrated means a smaller migration programme. This benefits the client. It may affect the applicability of the strategy tier where if Replace and Retire reduces the workload count below the tier threshold, we will discuss whether the remaining scope warrants a strategy tier adjustment.
Questions to ask before any migration commitment
Our cloud provider has offered us a free migration assessment. Why do we need this?
A cloud provider migration assessment has a commercial objective is to migrate your workloads to their cloud platform. The assessment will tell you how to migrate, not whether to migrate or whether their platform is the right choice. It will not model the licensing cost changes for your specific software estate against their pricing. It will not recommend Replace and Retire for workloads that would generate revenue if migrated. It will not assess a competitor’s platform. Our assessment is independent of any cloud provider and has no commercial interest in which platform you choose or whether any specific workload migrates at all.
We have a migration underway that is not going well. Can you help?
Yes. A failed or stalled migration rescue is a specific use case addressed in the Enterprise tier. The first step is an assessment of what went wrong and why: was it a strategy failure (wrong approach classification, missing dependencies, unmodelled costs), an execution failure (runbooks not followed, FinOps not implemented, parallel run periods not observed) or an infrastructure failure (architecture that cannot deliver the required performance or availability)? The rescue strategy addresses the root cause, not the symptoms. In some cases the right answer is to reverse completed migrations and re-execute with the correct approach. We will assess this honestly, including whether reversal is more or less expensive than remediation.
What is the real total cost of a 30 workload migration including everything?
Strategy fee from £22,000. Landing zone and FinOps implementation (by your team or partner) are typically £15,000 to £40,000 in labor. Migration execution labor for 30 workloads (mix of approaches) from typically £80,000 to £250,000 depending on approach classification mix which Re Platform and Refactor workloads cost more to execute than Lift and Shift. First year cloud infrastructure costs are typically £25,000 to £120,000 per year depending on workload types. Licensing cost changes are highly variable which could be zero or could add £50,000 to £200,000 per year for Oracle or Microsoft heavy estates. Training are typically £8,000 to £25,000 across the team. Total first year all in cost from £150,000 to £650,000 for a 30 workload migration. The TCO model in the strategy phase produces the specific version of this for your estate.
Can we skip the strategy and just start migrating?
Yes. Many organizations do. The consequences of cloud bills exceeding on premises, applications that break in migration, licensing costs that were not modelled, data residency obligations that were not understood, security configurations that were not implemented which are well documented in the industry. If the question is whether migration without strategy is possible, the answer is yes. If the question is whether migration without strategy is advisable for anything other than a small, simple estate with no regulatory obligations and no complex licensing, the answer is no. The strategy fee is the cost of not discovering these problems at cloud scale, after they are embedded in your cloud architecture and expensive to correct.
What if the assessment concludes that cloud migration is not the right decision for some workloads?
Then that is what it concludes, and we document it. A Replace and Retire classification is the right answer for a material proportion of workloads in every estate we have assessed which is typically 15 to 25%. A finding that specific workloads should not migrate does not fail the programme but it reduces the programme’s scope, cost and execution risk while improving the long term economics. If the assessment concludes that cloud migration for the entire estate produces a worse TCO than on premises for the next 5 years and which is rare but possible for some specific asset configurations as we document that finding. You paid for an honest assessment, not a migration mandate.
How do we know the strategy will work when our team executes the migration?
You cannot know before execution begins and neither can we. What you can know is the strategy was built from an accurate picture of your actual estate, every dependency was mapped, every runbook was reviewed for executability, every validation criterion is specific and measurable and every rollback procedure is executable given the infrastructure state at the point of failure. That is the maximum assurance a strategy can provide. What happens during execution depends on the accuracy of the estate disclosure, the fidelity with which the runbooks are followed and the infrastructure and licensing changes that occur between strategy completion and execution. We recommend engaging us for execution oversight on the highest risk waves and not because we expect problems but because problems during migration are less expensive to resolve when someone who designed the strategy is available to interpret what the runbook says to do next.
What are your payment terms?
50% on contract signature, 50% on written acceptance of the final deliverables. Scope additions (workloads above the tier ceiling, additional regulatory frameworks) are invoiced as they are agreed in writing which is never retrospectively. The final payment is contingent on your written acceptance. Acceptance cannot be withheld on grounds that were not raised during the document review cycles. If a deliverable does not meet the agreed specification, we remediate it before raising the final invoice. Migration execution oversight (day rate retainer) is invoiced monthly in arrears for days actually worked.
What happens if our business circumstances change during the strategy engagement?
Notify us immediately. Common changes that affect the strategy: acquisition or merger (the estate changes in scope and complexity), regulatory change (a new framework applies), major infrastructure change (a key system is being replaced independently of the migration programme) or budget constraint (the approved migration investment has changed). Each change is assessed for impact on the in progress work. Minor changes are absorbed. Material changes that require significant rework are treated as programme pause or scope change events, assessed per the programme contract. We do not simply continue working in a direction that we know has been invalidated by a change you have told us about.
Start with a migration assessment and bring your current cloud bills if you have them or the fact that you do not yet have any.
A 90 minute session reviewing your current estate, your regulatory position, your timeline pressures and any existing migration plans or cloud deployments where if you have current cloud bills, we review them in the session and cloud waste and misconfiguration are typically visible in the first 5 minutes of a billing console review.
At the end of the session you have an honest assessment of where your migration stands what the primary risks are, what the likely total cost is and whether a strategy engagement or a faster targeted intervention is the appropriate next step.
If you are already in a migration that is not going to plan, the session is still the right starting point as we assess what went wrong and whether the right intervention is a strategy reset, targeted remediation or execution oversight to bring an on track programme to completion.
Format
Video call or in person in London. 90 minutes.
Cost
Free. No commitment.
Lead time
Within 5 business days of contact.
Bring
Current cloud bills if any exist. Existing migration plan or cloud strategy documents. Brief overview of your estate with approximate workload count, on premises sites, cloud platforms already in use. Your primary regulatory obligations and any existing compliance certificates.
Attendees
Your IT lead or infrastructure manager. Optionally, whoever holds budget or regulatory accountability. From RJV with a senior cloud strategy consultant. Not a salesperson.
After
Written summary of session findings within 2 business days. Scope and fixed strategy fee within 5 business days if a strategy engagement is appropriate.