A free hosting migration can save time, but “free” describes the fee more clearly than it describes the work. Copying files is only part of moving a live website. You also need a plan for changing data, domains, email, external integrations and the moment visitors begin using the new environment.
Migration services differ by application, source host and support scope. Official documentation can establish available methods and exclusions, but your website may have dependencies that require separate work. Confirm the details for your specific installation before accepting a migration date or cancelling an existing subscription.
This checklist from getaboutcolumbia explains the questions that prevent common gaps in a free move. You will define what transfers, how new activity is preserved, who handles DNS and what evidence is needed before declaring the migration complete.
Ask what the migration actually includes
Provide an inventory of the website, database, uploads, domains, scheduled tasks and external services. Ask whether the offer covers a standard installation, custom directory layout, multisite network or unusually large archive. The WordPress migration process becomes safer when the provider knows the full scope before it starts copying data.
Kinsta’s migration documentation describes request paths using source-host information or a backup for standard WordPress installations. That is an example of a defined transfer workflow, not evidence that every surrounding service moves automatically. Ask separately about mailboxes, DNS hosting, domain registration, custom server configuration and applications outside WordPress.
Clarify who supplies access and how temporary credentials are handled. Prefer the provider’s supported secure process and grant only what the migration requires. Record which accounts or keys were created so they can be removed afterward. Never assume that a contractor who can access WordPress also has permission to change the domain or hosting billing.
Ask whether the service includes troubleshooting after the copy. A transferred website may depend on a PHP extension, filesystem path or mail configuration that differs at the destination. Agree on what the migration team will repair and what remains with your developer, particularly for custom code and licensed third-party integrations.
Establish how changing data will be preserved
A live website can receive orders, bookings, comments and uploaded files while it is being copied. Ask exactly when the database snapshot is taken and how later changes reach the destination. “No downtime” is not a complete answer unless the provider explains the mechanism that prevents the two copies from diverging.
Pressable’s migration instructions explicitly discuss orders created after a database copy and the need to plan around them. This is the central question for any transactional migration. Will writes be paused, will a supported synchronization process run, or will the site use another controlled cutover method? Confirm the answer before moving customer activity.
Consider a hypothetical store that receives fifteen orders after the first copy. Those orders exist in the old database unless a deliberate process transfers them. Pointing DNS back later is not a reliable merge strategy. Your DNS TTL migration plan must support the data plan, because visitors can continue reaching different servers during a transition.
Identify background writers as well as people. Payment callbacks, scheduled imports and subscription jobs can alter data even when a visible maintenance page is active. Ask how these will be paused, redirected or reconciled. Name the person who confirms that the final destination contains the authoritative order, account and content records.
Define cutover, verification and rollback
Ask who changes DNS and which records will change. If only the website is moving, preserve unrelated mail and verification records. Clarify certificate provisioning, redirects, scheduled tasks and external allowlists before the switch. The migration is not complete merely because the homepage appears at the new host.
Keep an independent recovery copy. WordPress’s backup documentation explains the need for both files and database; request a usable export before work begins. Know where the copy is stored and how it can be restored. A provider’s migration service should complement a recovery plan rather than become the only holder of the website’s data.
Prepare acceptance checks based on the website’s functions: login, search, form delivery, downloads and a safe transaction test where appropriate. Include email DNS checks during the move so an apparently successful website launch does not hide a broken mailbox or password-reset path. Test from more than one connection and inspect the destination logs.
Agree on a rollback decision point and who can authorize it. Returning traffic to the old host may be simple before new writes begin on the destination, but more complicated afterward. Define how changes will be reconciled if rollback becomes necessary. Keep the old service until acceptance is complete and a suitable overlap period has covered the transition.
Mistakes to avoid
Do not equate free migration with complete business-service transfer, cancel the old account immediately or allow both databases to accept writes without a reconciliation plan. Avoid changing the domain name, theme and hosting platform together unless the project explicitly requires it. Combining unrelated changes makes failures harder to diagnose and weakens the usefulness of the original working copy.
Two final recommendations
Request a written migration scope naming included sites, excluded services, expected customer tasks and post-move assistance. Add a clear answer for orders or other data created during the copy. Resolve those questions while the current website is healthy and accessible.
Create a short acceptance record with critical functions, the final data check and the person approving completion. Retain recoverable exports and temporary overlap until the checks pass, then remove obsolete credentials and cancel services deliberately rather than by assumption.
Conclusion
A free hosting migration is valuable when its scope and responsibilities match your website. The decisive questions concern changing data, dependencies, DNS, verification and recovery, not simply whether the provider copies files without charging.
Inventory the installation, agree on the write-handling strategy and define cutover and rollback before scheduling the move. Test business functions afterward and confirm that the destination holds the authoritative data.
Accept the migration only with a clear operating plan. Preserve independent backups and control of your domain, then retire the old environment once the new one has passed the agreed checks.
