Recovery depends on finding another machine
The backup exists, but the operating system, libraries and configuration still have to be rebuilt. A failed disk can turn into a long interruption.
Application server virtualization & migration
Protect your application from hardware failures and failed restores.
Recovery certainty. Restore times measured in minutes. Scaling, replication and versioning enabled.
Keep your working application. Reduce restore time, make it easier to move, and prepare it to scale, replicate and run identifiable versions. We reproduce the environment, test recovery and measure the time it takes before switching traffic.
Built and tested on a clone. Cutover after your approval. The recovery plan, data sync and route back are agreed before traffic moves.
For new clients: one free review covering one application on one server or hosting instance. Review terms →
Keep the application working
The current server keeps serving while the target is prepared.
Recovery certainty
Test the complete restore and measure elapsed minutes, so recovery time is known before a failure.
Scale, replicate and version
Prepare additional instances, controlled releases and data replication around the way your application works.
When one server becomes the limit
It runs today. What happens when the server fails—or the business grows?
The application still does its job. But a replacement server takes days to prepare, every update feels risky, and nobody has proved how long a restore will take. More customers mean more pressure on the same machine.
Moving the application gives you a chance to make recovery, maintenance and growth part of the setup.
Changes happen on the live server
Testing means touching production. Going back depends on remembering what changed and whether the database changed with it.
Capacity comes in whole servers
One busy service uses the machine while other resources sit idle. Adding capacity means another purchase, installation and migration.
The same problem appears in older hosted environments. An application in an OpenVZ or Virtuozzo container can be just as tied to its provider, host configuration and undocumented dependencies.
What becomes easier
Keep the working application. Improve everything you need to do around it.
Reduce restore time
Recover from a defined VM backup or application image, with its data and configuration. We rehearse the restore and record the elapsed time before calling it ready.
Add capacity as demand changes
Increase assigned CPU and memory, move to a larger host, or add application copies where the design supports it. The database and shared data are included in the plan.
Know which version is running
Keep identifiable releases, configuration and deployment records. Reproduce a tested version and plan how to return to it when an update fails.
Replicate for recovery and growth
Prepare additional copies of the application environment and an agreed way to keep their data current. A recovery copy can shorten the path back to service; serving copies can support growth where the application allows it.
Stop overpaying for cloud hosting
Want to leave AWS, Microsoft Azure or Google Cloud? We can move your application to suitable bare metal, a VM or containers. Compare hosting, storage, traffic and operating costs before choosing the destination.
Move without starting over
Carry a prepared environment to replacement hardware or another provider. Each move has a defined target, data transfer and cutover procedure.
Test before customers see it
Use a separate copy for updates and changes. Check the business functions, scheduled jobs and integrations before approving the switch.
Separate applications and dependencies
Give workloads their own environment and resource limits. Different applications can retain different libraries and runtimes without sharing the same installation.
Use hardware more effectively
Consolidate suitable workloads on one host and allocate resources deliberately. Keep dedicated hardware where the workload benefits from it.
Preserve a difficult legacy stack
A VM can retain an operating system and kernel. A compatible container can preserve application dependencies. The review establishes which approach fits.
Maintain the platform more easily
Separate the application environment from the physical server. Prepare replacements and updates with a planned maintenance window and rollback procedure.
Application server migration & containerisation
Bare metal, virtual machines, Incus, Docker and Podman.
We assess physical-to-virtual server migration, VM-to-physical deployment, system container migration and application containerisation. The destination is chosen around the application, its dependencies and the way you need to operate it.
Bare metal↔VM↔IncusVMs / system containers↔Docker↔Podman
↔ means we assess moves in either direction. These are migration options, not a required sequence or a promise of direct image conversion. Moving a whole server and packaging an application are different scopes of work.
| Route | What the move involves | What decides the scope |
|---|---|---|
| Bare metal ↔ VM | Capture and adapt the server for a virtual machine, or deploy the VM workload onto a physical host. | Boot mode, drivers, disk layout, hardware access and licensing. |
| Bare metal / VM ↔ Incus | Import a compatible Linux root filesystem into a system container, or a bootable disk image into an Incus VM. Export and redeploy for the reverse route. | Kernel requirements, bootability, network configuration and mounted data. |
| Bare metal / VM ↔ Docker / Podman | Package application services into images with persistent data outside the image. For the reverse route, redeploy the services and data onto the target OS. | Runtime dependencies, service startup, filesystem writes and integrations. |
| Incus ↔ Docker / Podman | Repackage services from a system container or VM into application containers, or deploy application services inside an Incus environment. | Whole-system dependencies, service boundaries and whether nesting is appropriate. |
| Docker ↔ Podman | Reuse compatible container images and adapt the deployment definition, persistent storage and runtime configuration. | Permissions, rootless networking, volumes, orchestration and API compatibility. |
| Bare metal ↔ bare metal | Prepare a replacement physical server, transfer the application and data, test, then cut over. | OS and hardware compatibility, capacity, final sync and provider networking. |
Incus manages virtual machines and containers. A system container shares the host kernel; a VM has its own kernel. Docker and Podman generally package application services. If the old application needs a particular kernel, we assess a VM before choosing a container.
Legacy OpenVZ and Virtuozzo migration
Move an older OpenVZ or Virtuozzo workload to Incus, Docker, Podman, a virtual machine or suitable bare metal. We inspect what is actually inside the source before deciding whether to preserve the complete environment or separate its services.
OpenVZ / Virtuozzo ↔ Incus
For legacy containers, capture the root filesystem and mounted data, then adapt startup, networking and permissions for an Incus system container. A VM destination requires a bootable OS; a container filesystem alone is not a complete VM disk.
OpenVZ / Virtuozzo ↔ Docker / Podman
Identify the application, web server, database, jobs and mail dependencies. Build application images and migrate persistent data. Reverse moves require a compatible target and a deployment plan rather than importing an OCI image as an OpenVZ container.
Virtuozzo environments may contain VMs as well as containers. We identify the source type and version, storage format, bind mounts, IP assignments, quotas and provider access. Where a direct move is unsuitable, rebuilding the runtime or using a VM is priced as a separate component.
A supported host does not make an unsupported guest operating system or application supported. Preserved legacy components still need an agreed maintenance and exposure plan. Legacy application rescue →
Choose the environment around the workload
| Environment | What it preserves | Isolation & operations | Capacity & releases |
|---|---|---|---|
| Bare metal | Dedicated hardware and direct device access. | Separate physical machine; the OS and application are restored together or rebuilt. | Hardware upgrades or additional hosts. Versioned code, configuration and installation scripts. |
| Virtual machine | Complete guest OS, kernel and application stack. | Own kernel; VM backups, templates and test clones. | Resize within host capacity or add VMs. Versioned templates and backups. |
| Incus system container | Linux userspace and compatible system services. | Separate userspace with a shared host kernel; instance backups, profiles and resource limits. | Adjust limits or move instances. Record configuration and environment versions. |
| Docker / Podman | Packaged application services and dependencies. | Shared host kernel; image-based deployments with separate persistent storage. | Add replicas where supported. Versioned images and deployment configuration. |
Restore time, scaling, replication and versioning are part of the engineering.
Restore timeAgree a recovery time objective (RTO) and acceptable data-loss window (RPO). Rehearse recovery from the actual backup, including database consistency, secrets, networking and business-function checks. Record measured elapsed time; image startup alone is not a complete restore.
ScalingVertical scaling adds resources within host capacity. Horizontal scaling adds instances and requires session handling, shared files, database capacity, load balancing and job coordination. Containerisation alone does not make an application horizontally scalable.
ReplicationSeparate application-instance replication from database and file replication. Define how changes reach the recovery or serving copies, the acceptable replication lag, and how traffic switches. Test consistency and prevent conflicting writers. Replication complements independent backups; it can also copy deletion or corruption.
VersioningRecord code revisions, image digests or template versions, runtime dependencies and configuration. Keep secrets separately. Database migrations and new writes need their own rollback strategy; returning to an old image cannot undo them.
AvailabilityMultiple workloads on one host still share that host's failure risk. Higher availability requires additional hosts, suitable data replication and failover. Live migration is assessed against the platform, storage, networking and workload requirements.
Platform references: Incus machine imports · Docker container execution · Podman documentation.
Review first.
Your migration process
The free review establishes the likely route, dependencies, target and scope.
01
Clone
Capture a consistent copy and prepare the target. Coordinate any database locks, write pause or capture load beforehand.
02
Test
Check application behaviour, jobs and integrations. Rehearse recovery and document the deployment and rollback procedure.
03
Cutover
After your approval: final sync and traffic switch during the agreed window. Validate the live service.
04
Rollback held open
Keep the source available for the agreed rollback period, with a plan for traffic and data written after cutover.
What you receive
A tested target environment, deployment and configuration records, backup and restore instructions, restore time measured in minutes, and a cutover and rollback plan. Where included in the agreed scope, scaling and replication procedures are delivered and tested. Version identifiers and resource settings make the delivered environment traceable.
Migration & containerisation
From $99–$199
Depending on dependencies and target. The review establishes the scope and total price before work begins.
Outside the migration
Hardware or hosting, licences, recurring maintenance, application refactoring and additional services are identified and priced separately where required.
Before you move
Does the application have to be rewritten?
No. Your application stays as it is. The move may require minor configuration adjustments, such as partition or filesystem paths and port settings. No major application changes are needed.
How much downtime should we expect?
The capture method, database size, write rate and network decide the window. We prepare and test the target first, then agree the final sync and traffic switch. A first migration is not assumed to be a zero-downtime operation.
Can you move us back to bare metal?
Yes. If we have just moved you from bare metal and the original server is still ready with current data, we can switch traffic back and turn it on if needed. If you are already running elsewhere, we can migrate your application onto bare metal. We confirm the target, transfer the data and test before switching.
Can you move us away from AWS, Azure or Google Cloud?
Yes. If cloud bills are too high for what your application needs, we can assess a move to bare metal, a VM or containers. Application hosting, databases, files and any provider-specific services are included in the migration scope and cost comparison.
Can you move an old OpenVZ VPS?
We assess its filesystem, services, mounted data and dependencies for Incus, a VM, Docker or Podman. Provider backups and container settings may need extraction and adaptation. Access and compatibility are confirmed before committing to a destination.
Are snapshots enough for recovery?
Snapshots are useful recovery points, but do not replace independent backups. Database consistency, retention, a separate failure domain and a verified restore procedure are part of the recovery design.
Will virtualization make it faster?
Containers generally run at near-native speed. VMs can also run close to bare-metal performance with suitable CPU, storage and network configuration. Where supported, SR-IOV gives the VM direct access to a network adapter’s virtual function, reducing virtual networking overhead. Storage configuration is another important factor: QCOW2 features such as copy-on-write and snapshots can add overhead compared with raw or directly assigned storage. We choose the setup around your workload and verify performance on the target.
Start with what you already have
Your application server needs recovery you can rely on, easy migration and the ability to scale.
Tell us what your application runs on, what it depends on and what you want to improve. We will assess the smallest suitable move and explain what it involves.
Useful starting details: OS and runtime versions, current platform, database and storage size, provider access, and your acceptable maintenance window. If some are unknown, start with what you know.
For new clients: one free review covering one application on one server or hosting instance. Review terms →