Cloud Migration Services that end with the old estate switched off, not still running.

Cloud migration is the move itself: applications, data and the integrations between them lifted off on-premise servers or an ageing cloud account and landed on a current platform such as AWS, Azure or Google Cloud. unicrew's cloud migration services cover the whole path: a fixed-scope migration readiness assessment, a target architecture, the estate sequenced into waves, the cutover, the pipelines and monitoring needed to run the result, and the cost work afterwards. Archiving and switching off the source estate is part of the service, not something left on your list.

We scope before we quote, because the answer depends on how many workloads move, how many can be rehosted unchanged, how much data has to be converted, and how many integrations have to keep working. The fixed-scope assessment exists to answer exactly that, and it is quoted on its own. Execution is then quoted against what the assessment found: outcome based per project, billed hourly and quoted per project, or billed monthly per team member if a team of ours runs it. Every estate gets its own quote, because a headline price would be wrong for most of them.

It follows the strategy rather than the calendar. In our delivery experience a contained workload rehosted unchanged lands in weeks, while re-architecting a monolith into cloud-native services runs across months. The assessment is where the schedule stops being a guess: once the estate is sequenced into waves, each wave carries its own window, and you are the one who says when that window can be. Automation moves the volume, not the date. We provision the target from Terraform rather than assembling it by hand, so a second environment is a command rather than a project, and none of that settles what travels with what, which integration cannot be re-pointed, or who signs off that the numbers reconcile. Those three are what a schedule is actually made of.

That is usually the larger half of the work. A migration is rarely one application: it is an application plus the ERP, CRM, payment providers, partner APIs, identity provider and reporting tools hanging off it. All of them are mapped during the assessment, because that is where schedule risk lives rather than in the servers, and on one on-premise CRM migration the dependencies and critical services were mapped before anything moved and the sequence built around them. Where an integration cannot be re-pointed, it decides which wave its workload travels in.

Most of them are on-premise Microsoft estates, on hardware in a room or on an old hosting arrangement somebody wants out of. The second shape is a cloud account that has aged, where the platform is fine and the services underneath it are years out of date. Four engagements rather than categories. An on-premise Microsoft estate on C#, SQL Server and ASP.NET, moved onto Azure. A desktop application that had to become a multi-tenant cloud SaaS product, with a thin client connecting it to each shop's own CRM. A WebForms platform whose hosting moved to the client's own AWS account while its main functionality was rewritten module by module. And a content platform for scientific congresses whose submitted media files were relocated onto AWS S3, which improved the reliability of those digital assets and made them easier to manage. If yours is a different shape, bring it to the call and we will map it against what we have moved.

That is set in the plan, wave by wave, and you set each window. A phased cutover groups workloads into slices that move independently, so the question is never how long the whole estate is down, only how long this slice is. The source keeps serving whatever has not crossed yet, which is why both estates are on the bill until the last wave lands. Integrity checks run on both sides of each move, and we ask you to verify on your own side too: the people who know what the numbers should say are the ones who catch a problem. On one on-premise CRM migration to Azure the move completed without significant issues and eliminated the downtime of the old setup. On a hotel booking platform whose move ran against a clock, the result was near-zero downtime.

Six things can happen to a workload in a move, and the industry calls them the 6 Rs. Rehost (lift and shift) moves it onto cloud VMs such as Amazon EC2 or Azure VMs with little or no code change: the lowest effort, and it fits when you need out of a data center fast. Replatform keeps the application and adopts managed services such as Amazon RDS or Azure SQL: medium effort, less operations overhead, no rewrite. Refactor, or re-architect, redesigns into cloud-native services such as containers, Kubernetes or serverless: the highest effort, and worth it when the design itself caps scale. Repurchase replaces the workload with a product you buy, which is usually right for something you do not differentiate on. Retire switches off what nobody uses any more, and finding those is part of what the assessment is for. Retain leaves a workload exactly where it is, on purpose, with the reason written down. An estate rarely has one shape, so the call is made per workload.

A current-state review of your applications, data and dependencies; target architecture options on AWS, Azure or Google Cloud with the trade-off called out per workload; a per-workload call across the 6 Rs; the estate sequenced into waves, so what moves first and what goes last is decided rather than assumed; and a total cost of ownership (TCO) view for running the target. It is written to stand on its own, as the business case for the decision and its timing. This is the part of the work usually sold as cloud migration consulting, and here it is a deliverable with a fixed scope and a price of its own.

It pays off when demand is volatile or growing, when a hardware refresh is due, when releases are slow because environments are hand-built, or when resilience matters more than your own servers can deliver. Where load is flat and predictable, the hardware is already paid for and nothing on the roadmap needs elasticity, the cloud usually costs more rather than less. The assessment puts your estate against both lists and gives you the answer in writing.

Yes, provided the environment is configured correctly, which sits with you and your partner rather than with the provider. Under the shared responsibility model the providers cover physical security, platform patching and the encryption primitives; identity, network configuration, key management and access policy are yours and ours, and the assessment writes down which is which. A move also decides where the data sits, which is a GDPR question before it is an architecture one: the region each workload lands in, what is allowed to leave it, and who can reach it from where are settled while the plan is being written rather than on cutover night. unicrew holds ISO 27001:2022 and ISO 9001:2015, renewed through a multi-stage audit with Quay Audit UK, and ISTQB-certified QA sits inside every sprint. Our security practice is one dedicated security engineer plus a part-time senior security consultant, so a security review is scoped into the plan rather than assumed free.

Contracts and NDAs first, signed before anyone gets access to anything. For the assessment we work from read-only, least-privilege access, agreed with your technical contact before anything starts, with no write access to production systems during discovery. For the build and the cutover, the cloud accounts are opened in your own name, and we work inside your own cloud environment where your customers, insurers or shippers require it. All of it is in writing before anyone starts.

Yes, and usually for longer than the business case assumed. A phased cutover means the source estate keeps serving whatever has not moved yet, so for the length of the move you are paying for both. That is not waste, it is the price of not betting the company on one weekend, and it belongs in the plan before the first wave rather than being discovered in month three. A data warehouse is the clearest case: reporting has to keep answering off the old one while the new one is loaded, and the two are compared before anything is pointed at the new one. It ends when the last wave lands and the source is archived and switched off. What the target costs to run after that is what the cloud cost and AI-readiness audit reads.

The wave is the unit of progress, so there is always a countable answer: which workloads have crossed, which are scheduled next, and what the assessment said would be hardest. A wave is not counted as done because it moved. It is done when the integrity checks reconcile on both sides and your own people have verified it, which is why the next window is only scheduled after the previous one closes. Between windows the honest measure is not activity, it is how much of the source estate is still serving traffic, because that is also what you are still paying for. The plan set at the assessment is the list you are counting against, and it is a deliverable of that engagement rather than something you wait for.

It can, and the ways are boringly consistent: a hostname or IP written into a config file years ago, a scheduled job nobody knew was running, a file path that used to be local and is now a network call, a timezone or a locale inherited from the old server, and latency between two components that used to sit in the same rack. None of that shows up in a server-level copy, which is why the assessment reads the application and not only the infrastructure. Each wave then carries integrity checks on both sides, and we ask your own people to verify, because they are the ones who know what the numbers should say. Where a workload has to change shape to survive the move, that is a refactor and it gets scoped as one, rather than being discovered on cutover night.

Compare on what is checkable from outside a proposal. First, the client review behind the rating: an interview tells you what the engagement was like, and every client quoted above opens their own. Second, what happens to the source estate after the last wave lands, and who pays for the overlap while both are running: ours ends with the source archived, switched off, and the maintenance and licence contracts under it closed. Third, which certifications a firm holds and who audited them: ours are ISO 27001:2022 and ISO 9001:2015, renewed through a multi-stage audit with Quay Audit UK. We answer all three before you sign.

When the estate is more than one standard site or one packaged application: a decade of dependencies in it, integrations you do not control that have to keep working on the other side, an application that matters as much as the servers, and a source environment somebody has to be accountable for switching off. When you want the plan and the cutover date built from an assessment of the estate, so the schedule follows what the estate actually needs. And when you want engineering hours that overlap fully with European working days and partly with US ones: unicrew is a nearshore engineering partner whose project managers and engineers work from Ukraine, Poland, Estonia and the UK, four of the six countries its 100+ senior in-house engineers span. Estates like the first one are the work we are built for.