For custom website development, if the server provider changes, can the old admin and order data be migrated as-is?

Moving a website to a new server is usually not just a matter of packaging files, downloading them, and uploading them again. What tends to cause problems is not the files themselves, but misalignment across the database, DNS, SSL certificate, email configuration, scheduled tasks, and caching. Based on common 2026 delivery experience, a pure showcase website can usually be migrated smoothly in 1–3 days if preparations are sufficient; sites with memberships, orders, or third-party APIs usually need a longer window and a rollback plan prepared in advance.

Why does “moving the files over” often not mean the website has been migrated properly?

A website runs on three parts: files, database, and server environment. Files usually contain only program code, templates, and static assets; articles, product data, member information, and form records are mostly in the database. If you move only the files without importing the database, common symptoms include categories being present but content being empty, or being unable to log in to the admin. Another type of problem is environment differences: if the runtime versions, rewrite rules, or upload directory permissions differ between the old and new servers, the code may upload successfully but pages may throw errors.

• File layer: themes, plugins, uploaded images and attachments;
• Data layer: articles, products, members, orders, form records, configuration items;
• Environment layer: runtime version, rewrite rules, directory permissions, scheduled tasks, email sending method;
• External layer: DNS, SSL certificate, CDN cache, third-party API callback URLs.

If any of these four layers is misaligned, it will show up as “the site won’t open after migration” or “it opens but something is wrong.” Therefore, migration acceptance criteria cannot be based only on whether the homepage displays. This is also the key difference from simply uploading files.

Deciding whether to do this migration yourself or get help

There is no one-size-fits-all answer for how to migrate; first look at site complexity. Based on 2026 project delivery practice, sites can be divided into three types: pure showcase, dynamic content, and sites with business systems. Different types have different downtime windows, rollback difficulty, and cost ranges.

1. Pure showcase: not many pages, no members or orders, and few database changes. It can commonly be completed in 1–3 days. The prerequisite for doing it yourself is having server access and database export files.
2. Dynamic content: has articles, products, forms, and admin editing, and the database needs to be fully exported and imported. Commonly 3–7 days. It is advisable to set up a test environment on the new server first and switch the domain only after confirming everything is correct.
3. Sites with business systems: have members, orders, payments, or external APIs, and the migration window should avoid business peaks. Commonly 1–2 weeks or longer, and usually requires help from the developer.

If it is only a showcase website and the provider offers image migration or one-click migration, doing it yourself is relatively less difficult. But when orders and payment callback URLs are involved, third-party backend configurations must be updated in sync after changing servers; missing that change can lead to successful payments but order statuses that do not sync.

• Do it yourself: the main cost is time, suitable for teams familiar with the admin and database;
• Help from the original provider: familiar with the old environment, clear responsibility boundaries, commonly billed per instance or per hour;
• Third-party technical help: requires an environment audit first, commonly quoted per project, with a wide range.

The numbers in this comparison are experience ranges; specifics should be based on the actual environment and the provider’s quote. The criterion is not “which one is cheaper,” but who can complete a rollback drill within the downtime window you accept.

Checklist to review before migration

A common situation in projects is that the client gives only a very short downtime window while also requiring that no admin data be lost after migration. The tighter the constraints, the more important it is to back up and rehearse first, rather than operating directly on the production server. In one delivery scenario, the client had a limited budget and would allow only half a day of downtime. We first lowered the DNS TTL, exported the database, and rehearsed on the new server. It turned out the old site had a scheduled task running; if it had not been stopped in advance, it would have sent duplicate notifications, and rework took extra time. This kind of cost is usually not money, but site downtime and indexing fluctuations.

• DNS: lower the TTL in advance, and confirm it has taken effect as soon as possible after switching;
• Database: export completely and verify record counts; do not export only some tables;
• SSL: deploy the certificate on the new server in advance and test the renewal method;
• Email: confirm the SMTP configuration works and that form notifications and admin emails are normal;
• Scheduled tasks: review the cron jobs on the old server; stop what can be stopped and migrate what can be migrated;
• Rewrite rules and redirects: keep the old URL rules to avoid sitewide 404s;
• Upload directory and permissions: sync images and attachments, and set directory permissions according to platform guidelines;
• Backup and rollback: keep the old server data for a period and do not rush to release it.

Specific parameters can be checked against the server provider’s official documentation and platform guidelines. In our enterprise project delivery practice, whether the checklist has been completed properly is judged by whether, after the switch, you can independently complete this sequence: “open the homepage, enter the admin, publish an article, submit a form, and receive the notification email.”

Common pitfalls after migration and acceptance criteria

A significant portion of post-migration problems are not caused by broken code, but by caches and DNS not being cleared properly. If the old server is still running, during partial DNS propagation different networks may see either the old site or the new site. If the CDN cache is not purged, content changed in the admin may not change on the front end. Another common pitfall is image 404s, usually caused by an unsynced upload directory or a case-sensitive file system.

• Homepage opens but category pages 404: rewrite rules were not migrated;
• Admin login works but front-end styling is broken: static asset paths or cache issues;
• Form submits successfully but no email is received: SMTP configuration or sending permissions were not changed;
• HTTPS shows insecure: the certificate was not deployed, or the page still contains http resources;
• Payment or API errors: callback URLs still point to the old domain;
• Indexing fluctuations: many 404s or redirect chains appear during the switch.

Acceptance criteria can be checked against a list: core pages are accessible, record counts in the main database tables match, form notifications are delivered, HTTPS works normally, mobile layout is not broken, and server logs do not show a mass of 404s. If these are not met, the migration is not complete, and it is not advisable to release the old server.

Applicable scenarios and boundaries

Typical scenarios suitable for migration include: the old server is expiring and renewal is clearly more expensive than buying new, traffic growth has led to insufficient resources, the original provider is discontinuing service or responding slowly, or compliance or ICP filing requirements require changing data centers. In these cases, migration is a necessary action to solve the problem.

Cases that are unsuitable or not urgent to migrate should also be stated clearly: if you merely think “another provider might be cheaper,” while the site itself is accessible and needs no technical maintenance, a hasty migration may bring downtime, indexing fluctuations, and email interruptions; if the price difference is small, first check the renewal plan and whether the configuration is sufficient. For a showcase website without technical staff, if the provider can still maintain it normally, this matter usually has lower priority than content updates and indexing optimization.

Boundary statement: Website migration is better suited to solving specific problems such as expiration, performance, or provider changes, rather than being a routine operation for “wanting a change.”

FAQ

Does website migration always require downtime?

Not necessarily. A common approach is to set up the environment on the new server and import the data first, then switch DNS, reducing downtime to the tens of minutes to several hours it takes for DNS to take effect; sites with order systems are advised to allow a maintenance announcement window.

Will Baidu indexing drop after migration?

Short-term fluctuations are common and are usually related to DNS switching, 404s, and redirect chains. If you keep the old URL rules, implement 301 redirects well, and submit a new sitemap, most sites will gradually recover indexing, but the recovery period varies by site foundation.

What are the main risks of doing the migration yourself?

The main risks are incomplete database import, missed email and scheduled task configuration, and lost rewrite rules. Risk for a showcase website is relatively manageable, but for sites with members or orders, doing it yourself without a rollback plan is not advisable.

When can the old server be released?

It is advisable to release it after the new server has run stably for a period; a common retention period is 1–4 weeks (experience range). During that time, if data loss or DNS anomalies occur, you can still switch back to the old environment.

If you are preparing to change servers, first make a complete backup, then lower the DNS TTL, and rehearse the “homepage—admin—form—email” chain in the new environment. Switch the official domain only after confirming everything is correct. For sites with orders, members, or external APIs, it is advisable to include the rollback plan in the delivery checklist and update third-party backend callback URLs in sync. Based on common 2026 delivery practice, a successful migration is not judged by whether the homepage opens, but by whether all core business actions can run through.