Move your infrastructure without a bad weekend.
Most people call us the month a bill jumped, or the week a console change broke something that used to work. We price the equivalent footprint against our published rates, plan the cutover with you, and leave the old environment standing until you are satisfied with what runs here.
Cutover plan
us-central-001Where people come from
Four starting points cover most of what we are asked to move. The work is different in each one, and so is the part that quietly goes wrong when nobody looks at it first.
From a hyperscaler
These moves usually start on AWS, Microsoft Azure, or Google Cloud, and the driver is usually a bill nobody on the team can forecast from one month to the next. The compute side of that is the easy half. The work is untangling which managed services you genuinely depend on and which ones arrived because they were one click away: a queue, a managed database, a scheduler, an identity service. Some have a plain equivalent on a server you control, some are worth keeping where they are and reaching across to, and some are a rebuild we will price honestly rather than fold into a migration quote.
From another VPS provider
The mechanical part of this is straightforward. Disk images are standard on both ends, they move cleanly, and the machine that boots here is the machine you shut down there. The care goes into everything around the disk: DNS records and the time to live on them, certificates and what renews them, and the addresses hardcoded into config files that nobody has opened since the last time this happened. We find those during the inventory, because the alternative is finding them during the cutover, with the clock running and somebody on the phone.
From your own server room
Hardware reaches end of life, a lease comes up that you no longer want to sign, or the person who understood the room has moved on. Moving those workloads onto virtual machines is one answer. Colocation is the other, and it is a better one if the machines are recent and you would rather keep them: both of our facilities take customer hardware today, so what changes is where the racks live and who walks over when a drive fails. We will tell you which of the two your situation calls for before you have spent anything.
From nowhere yet
An application that has only ever run on a laptop still needs somewhere to live, and there is nothing to migrate. The inventory is the same conversation held forward instead of backward: what the thing needs to run, what it stores and how much of it, what has to be reachable from outside, and what happens on the day it is busier than anyone planned for. Then it gets provisioned once, properly, rather than growing out of whatever was fastest to stand up.
How the cutover goes
A migration is mostly bookkeeping. The parts that hurt are the ones nobody wrote down: a cron job on a machine that predates the current team, a certificate somebody renews by hand, an IP address sitting in a config file that has not been opened since it was written.
So the work runs in five steps, and your current environment carries traffic through four of them. Nothing is switched off because a schedule said it should have been by now, and nothing is decommissioned while you still have questions about the thing that replaced it.
Scope is agreed per engagement. How much of this we run and how much your team runs is part of that conversation, and it is settled before the work starts rather than discovered in the middle of it.
- Step oneInventory and priceWe list what you run now: instance sizes, storage, what talks to what, which managed services you depend on and which ones you only think you do. That list is priced against our published rates, so the number in front of you is the number the dashboard would charge. If the equivalent footprint here is not cheaper, this is the step where you find out.
- Step twoBuild the targetWe provision the target while your current environment keeps serving traffic. Instances, storage, networking, and access are built to the inventory rather than to a guess. Where an application is deployed rather than copied, the deployment configuration is created here, and it can be updated or deleted from the dashboard whenever you need to change it.
- Step threeSync and verify parityData moves across, then the new environment is checked against the old one. The application starts, the database holds what it should, certificates are valid, the jobs that run overnight still run. You get access to the target and test it yourself, on your own list rather than ours. Parity is something you agree to, not something we announce.
- Step fourCut over at a time you pickYou choose the window. DNS moves, traffic follows, and the source environment stays up behind it the whole time. How long the switch takes depends on what is being switched, and any duration we quoted before the inventory would be a guess dressed up as a commitment.
- Step fiveDecommission only on your wordThe old environment comes down when you tell us to bring it down, not when a plan says the project should be over. Until then you have somewhere to fall back to. If you decide the move was wrong, your disk images are standard and exportable, there is no migration fee, and there is no notice period.
What changes about your bill
Compute here is not metered. You reserve a footprint and pay the same amount whether it idles through a holiday or runs flat out through a launch. There is no per-hour billing and no compute overage line, which means the number you agree to during the inventory is the number that arrives every month afterwards.
Bandwidth carries a base speed tier and a data allowance. Reaching the allowance drops you to the base speed until the next billing cycle at no extra charge, and that is the default rather than an option you have to find. Overage billing exists for the case where you would rather keep full speed, and you have to opt into it.
Billing is monthly and prorated to the day, with no setup fee and no minimum term. A resource added mid-month is billed for the days it existed. Leaving works the same way: standard exportable disk images, no proprietary format, no migration fee, and no notice period.
- Compute is not metered, so the invoice does not follow your CPU
- At the bandwidth allowance the default is a speed drop, not a charge
- Overage billing is opt-in, for when you would rather keep full speed
- Monthly billing, prorated to the day, no setup fee, no minimum term
- Standard exportable disk images on the way in and on the way out
What we will tell you not to do
Sometimes the honest answer is to stay where you are. We would rather say that during the inventory than six weeks into a project, when the only thing that has changed is how much of your time it has taken.
If you depend on a managed service with no equivalent on this platform, moving it means rebuilding it, and a rebuild is a software project with its own cost, its own timeline, and its own way of going wrong. We will tell you what that involves as a separate piece of work rather than folding it quietly into a cutover plan.
If your compliance position needs separation across regions, we cannot give you that. We operate two facilities and both are in Des Moines, Iowa. US Central 001 carries production and US Central 002 is the disaster recovery site, which is redundancy across sites in one metro rather than across geography. If an auditor is asking for distance between your primary and your recovery copy, two buildings in the same city are not the answer, and you should hear that from us at the start.
And if the better home for a workload is a cloud account you already own, we will help you deploy into it. Our software practice works in AWS, Microsoft Azure, Google Cloud, and DigitalOcean under your own billing and your own access controls. That is a different engagement from moving you here, and we would rather run it than talk you onto a platform that fits us better than it fits you.
- A managed service you genuinely depend on with no equivalent here, where moving means rebuilding
- A compliance position that needs distance between your primary and your recovery site
- A cloud account you already own and would rather keep, which we can deploy into instead
- Hardware you bought recently, where colocation moves the machines and leaves them yours
Questions we get asked before a move
What people want settled during the first call, answered the way we would answer it on the phone.
How much downtime should we expect?
What does the migration cost?
What happens to our current environment during the cutover?
Will our bill be lower?
What happens if we go over the bandwidth allowance after moving?
Can you move us into our own cloud account instead?
Where will our workload physically run?
What if we want to leave later?
Where a migration usually lands
Most footprints end up on virtual machines here, and some arrive as your own hardware in our racks instead. If the right home turns out to be a cloud account you already own, that is a job for our software practice rather than a migration.
Start with the number.
Tell us what you run today and we will price the equivalent footprint against our published rates, before anyone touches a disk image. If it does not save you anything, that is a useful answer too, and you will have it early enough for it to be worth something.