Overview
You move to the cloud on a controlled schedule, with email and logins switching once, file access tested before staff arrive, and a rollback path if something behaves differently than expected. The first month ends with runbooks your team can follow and a cost baseline you can track.
Our cloud migration cutover plan gives you a written change window, a pilot run, and a rollback path before anything switches in production. Next up is discovery and an inventory, then we map the cutover steps and owners.
We start by walking the environment with you and writing down what is actually running, who uses it, and what would break if it moved. From there we build the landing zone, migrate one small workload as a pilot, then run cutover with a timed checklist, live validation, and rollback steps that are ready before we begin.
About us
We are Cochinilla Systems, a four-person team that gets called when a server closet is about to become a risk. We do cloud migrations as planned change windows, not as open-ended projects. We inventory first, we test with a pilot, and we write the rollback steps while everyone is still calm and the old system is still there.
Most outages during a move come from two gaps: something nobody listed, or a switch-over step that only existed in somebody’s head. We close both. You get one inventory sheet that matches the cutover checklist, and one owner for each step. We also price the cloud you end up using, because a migration that “works” but doubles the bill is still a problem.
Who you will work with
You will deal with the same four people from discovery through cutover, with clear owners for each part of the move.
Team
Mariana Zárate, Cloud migration lead. Mariana runs the cloud migration cutover plan, writes the cutover and rollback steps, and keeps the switch-over inside the agreed change window.
Jorge Lira, Network and VPN engineer. Jorge handles the network edge: site-to-cloud VPN or SD-WAN, firewall rules, and the routing changes that keep stores and back office talking.
Paola Reyes, Microsoft 365 specialist. Paola leads Microsoft 365 moves, including identity, mail flow, DNS changes, and the checks that confirm people can sign in and send mail.
Iván Castellanos, Systems migration engineer. Iván migrates servers and databases, sets up replication where it fits, and runs the before-and-after validation so we know the workload is whole.
Selected work
Here are three recent migrations that needed tight cutovers, predictable login behaviour, and a cloud bill that stayed explainable afterwards.
Portfolio
Two-site retail cutover. Moved email and shared files, then migrated one line-of-business server. Cutover happened overnight, with a timed checklist and a rollback point held until morning validation was complete.
Server closet exit. Replaced end-of-life hosts by migrating two VMs and a small database to the cloud. Built the landing zone first, then ran a pilot VM to prove networking, backups, and monitoring before cutover.
Microsoft 365 tenant move. Migrated mailboxes and identity with staged batches, then ran the DNS and sign-in switch at a set time. Staff arrived to the same usernames, working mail, and tested mobile clients.
“Cutover weekend went to plan, and Monday opened with email and files working.”
Operations manager, a small multi-site chain
The service schedule
We run this as a controlled change window: we agree what is moving, we test the path with a pilot, then we switch with a timed plan and a rollback point. Between steps, you can reach us by phone or email and get the same people, not a queue.
1. Discovery and walkthrough Once, at the start We do a discovery call, then walk through what is on-prem and what staff rely on. You will tell us who owns each system and what “working” looks like. We capture access we need, maintenance windows you can tolerate, and any dates you cannot risk. 2. Inventory and plan Weekly We build and review the application and data inventory sheet with you, then turn it into a cutover plan with step owners and timings. You will see which items move first, which items wait, and exactly where the rollback points sit before any switch-over. 3. Pilot and prep Each month We build the landing zone, hybrid connectivity, and identity foundations, then migrate one pilot workload to prove networking, permissions, backups, and monitoring. You will validate access with a small test group so we catch surprises while the stakes are low. 4. Cutover and stabilisation Every visit We run the cutover plan in the agreed window, including DNS and identity switch-over, then validate live with you against the inventory. After cutover we fix edge cases, tune monitoring noise down, and keep a rollback option until the new state is stable.
Application and data inventory
Completed during discovery, then updated through the project. It lists what is moving, dependencies, owners, and the test you will use to confirm each item works after cutover.
CUTOVER PLAN AND ROLLBACK STEPS
Written before any production switch-over. It includes timing, step owners, validation checks, and a rollback point you can call without negotiation if a critical service misbehaves.
LANDING ZONE BUILD-OUT
Set up once, early. We configure networking, IAM, and tagging standards so new resources land in the right place and you can tell what they are for on the bill.
Workload migration execution
Run in planned batches. We migrate servers, databases, and Microsoft 365 as agreed, and we validate each workload against the inventory tests before we mark it complete.
HYBRID CONNECTIVITY SETUP
Built and tested before cutover. We set up site-to-cloud VPN or SD-WAN, confirm routing, and run failover tests so you know what happens if the tunnel drops.
STABILISATION, RUNBOOKS, AND COST REPORT
Delivered after cutover. You get handover runbooks for day-to-day operations, a monitoring tune-up, and a cost baseline with rightsizing actions you can approve or decline.
What it costs
Most teams pick the middle plan when there is more than one site or any line-of-business app. We confirm the final number after the first inventory week. Prices are per month.
Priced items
Getting started
Sign to reserve the discovery and cutover planning window, then we will send the access checklist and book the environment walk-through.
1. Sign this proposal to start the cloud migration cutover plan. 2. Intro us to your technical and operations contacts for access and approvals. 3. Book the discovery call and walk-through so we can build the inventory.
Signature
Fee summary
Are we going to be down, and for how long?
We plan for either no downtime or a short, scheduled interruption, and we put the number in the cutover plan before we book the window. We also hold a rollback point until validation is complete, so “down” never turns into “stuck.”
WHAT EXACTLY ARE WE MOVING, AND WHAT ARE WE LEAVING ON-PREM?
The inventory sheet is the source of truth. It lists each workload, where it will live after the move, and what it depends on. If something is staying on-prem for now, it is named there, with the reason and the connectivity it needs.
What do you need from us to get started?
We need a technical contact for access, an operations owner who can approve a change window, and credentials for the current environment and the target cloud tenant. We will give you an access checklist so you can see what we are asking for and why.
HOW DO WE MAKE SURE THE CLOUD BILL DOESN’T GET OUT OF HAND?
We set tagging standards in the landing zone so every resource has an owner and a purpose. After cutover we produce a cost baseline and a rightsizing report, then we review which changes you want to make and which you prefer to leave alone.
Payment
We invoice each month at the start of that month. Nothing is due before the first invoice. Each invoice is payable within 7 days of its date.
Access. To keep the cutover controlled, we need a technical contact for access and an operations owner who can approve a change window. We will send an access checklist, and we do not place passwords or MFA codes in this document.
Scope control. The application and data inventory sheet is the scope list we work from. If something is not on that sheet, we will pause and confirm whether it is in scope before we migrate it.
Change windows. We only run cutovers inside an agreed change window. The cutover plan will name the window, the expected interruption if any, and the rollback point. We do not book the window until you have that plan.
Rollback and validation
We hold a rollback point until validation is complete. If a workload fails validation, we follow the rollback steps in the cutover plan and reschedule the next attempt once the cause is fixed.
What this plan does not cover. This cloud migration cutover plan covers discovery, inventory, landing zone, migrations, cutover, and stabilisation. Work outside that list, like new features or app redesigns, is handled as a separate quote or time and materials.
Third parties. If an ISP, software vendor, or POS/ERP provider needs to make changes on their side, we will coordinate the window and testing with them. Their fees and timelines stay with them, even when we are on the call.
