Know What Needs to Move Before You Move It.

Start with the source platform, the destination you are considering, the components being moved and an approximate data inventory. Identify website files, databases, mail, DNS, runtime and external services separately. Confirm what access is available and whether the application continues accepting writes or transactions. This information starts the review; it does not establish automatic compatibility or a cutover guarantee. The Readiness Checker highlights information gaps without asking for credentials.

Access may be needed for activities included in the agreed migration scope, but the method and permissions depend on the source and workload. Do not enter passwords, private keys or API tokens in this checker. It only asks you to describe the access level using selections. Agree a secure method with WebCare360 support before providing sensitive details. Do not assume a public contact form is the right place to send secrets.

Some workloads can reduce interruption by preparing the destination, copying in advance and carefully synchronizing later changes. Continuous transactions, mail delivery, application state or IP dependencies can require controlled maintenance. DNS caching adds another consideration. The right cutover approach depends on the actual system and must be agreed before production changes. Selecting “Minimize interruption” in the checker records a requirement; it is not a promise of zero downtime.

Hosting-panel or account access is commonly useful, but the precise transfer method determines the permissions and exports needed. Review domains, files, databases, mail, cron and SSL as separate parts of the account. A hosting-account move is not the same as a complete server migration, so full root access should not be assumed necessary. Source-panel selection in the checker describes your current environment and does not promise automated support for that panel.

Identify the WordPress files, uploads, themes, plugins and database, together with the application runtime and rewrite behavior. Hosting, file and database access may be needed; WordPress administration can help depending on the method. Review caching, scheduled tasks and external services as well. An active shop needs a plan for new orders during cutover. WebCare360 WordPress Hosting remains coming soon, so confirm destination availability rather than planning around an assumed launch date.

Inventory the operating system, packages, users, services, ports, firewall, storage and network configuration alongside application data. Administrative access generally supports a full-stack review, but an application-only move may have a narrower scope. Identify licensing, hard-coded IPs, workers and external dependencies before deciding what to rebuild or copy. Full-server migrations need individual review; selecting a source or destination category does not establish identical management responsibilities for every service.

No. Email may be in the hosting account, with an external provider or on a separate server. First decide whether it should move at all. If it does, agree the mailbox and historical-mail scope, aliases, forwards, authentication records and any client changes. If it stays elsewhere, preserve the relevant routing and authentication configuration. Website transfer completion alone says nothing about mail delivery or the availability of historical messages.

A hosting move does not necessarily require changing DNS provider. The existing zone owner may update the relevant records while leaving nameservers in place. Review A/AAAA, CNAME, MX and authentication records together with proxy or CDN behavior. Separately verify certificate coverage and renewal arrangements on the destination. Copying website files does not prove HTTPS will work. Agree who can make the routing and certificate changes before scheduling the cutover.

Database size affects transfer and validation, but it is only part of the work. Engine compatibility, export/import behavior and ongoing writes also matter. A large mostly static dataset and a smaller transactional database can need very different cutover approaches. Check file count, mail volume, retries and the source’s transfer characteristics as well. The checker deliberately produces no time estimate from the selected data-size band.

List every known dependency before the destination changes. Examples include hard-coded connections, remote database rules, firewall allowlists, payment callbacks and software licenses. Some changes are controlled by the application owner; others require an external provider or vendor. A DNS change does not update every IP-bound dependency. Agree the required actions and test them on the new environment as part of the cutover plan.

Do not cancel the source before migration and post-cutover validation are complete. Keep the required access and data available while the agreed checks and any final synchronization are performed. Confirm how long the source should remain available for this particular move with the responsible teams; there is no universal retention duration on this page. Avoid scheduling cancellation solely around the completion of an initial file transfer.

Discuss requirements before ordering when the workload has a custom stack, large dataset, significant mail, continuous writes, unusual networking or IP-bound licensing. An uncertain destination size or business-critical cutover is also a reason to review first. Share the non-secret source, data and workload outline through the contact route, then agree scope and access arrangements. The checker helps organize that conversation; it does not book a migration or authorize production changes.