Alternative Migration Methods¶
File-level and application-native migration paths for deploy-first workloads that do not require Carbonite Migrate.
Section Overview
This section covers migration methods that follow the same deploy-first model (provision the target VM first), but use lighter-weight approaches suited to workloads where OS-level replication is not needed. These methods are best when the important asset is file data, application state, or a database export — not the source OS instance itself.
Methods covered¶
-
File and Data Migration
Move file-server data using Storage Migration Service (SMS) or Robocopy. Right for file servers and content repositories.
-
Application-Native Migration
Migrate SQL Server, IIS, and Linux/database workloads using the application's own export, backup, or replication tooling.
When to use these methods instead of Carbonite¶
| Situation | Recommended method |
|---|---|
| Workload is a Windows file server | SMS or Robocopy |
| Workload is stateless or easily rebuilt | Robocopy or simple re-deploy |
| SQL Server workload with a clean backup/restore path | Application-native (SQL backup/restore) |
| IIS or web application workload | Application-native (IIS export/import) |
| Linux app with rsync or native DB tooling available | Application-native (rsync / database dump/restore) |
| OS state must be preserved | Use Deploy-First with Carbonite instead |
Pages¶
- Prerequisites — Readiness requirements for SMS, Robocopy, and app-native paths
- Runbook — Step-by-step execution for each method
- Validation & Checklist — Validation and rollback guidance
Primary migration path¶
If you need low-downtime OS-level replication, use Deploy-First with Carbonite Migrate instead.