Moving a local WordPress install to live hosting comes down to three things: get the database and files onto the server, fix every URL reference that still points to your local address, and confirm the site actually works before you point DNS at it. Skip the URL fix and you'll get a site that loads with broken images, dead links, and a login redirect loop.
You can do this with the block editor and default WordPress tools for most sites. Reach for a migration plugin only when the manual steps below get unreliable, which mostly means large media libraries or WooCommerce stores with live order data.
Before you start: get hosting ready
Log into portal.flashcloud.com and confirm the domain is attached to your hosting plan, then create the database first. Open MySQL Databases from the Services page, create a new database and a database user, and assign the user to the database with full privileges. Write down the database name, username, password, and host (usually localhost) since you'll need them in a few minutes.
If you're moving an existing live site rather than a brand-new local build, take a fresh backup first. See Backing up your WordPress site for what's already running on your account and how to trigger an on-demand copy.
Move the files
Zip your local WordPress root (everything alongside wp-config.php: wp-content, wp-admin, wp-includes) into a single archive. Log into File Manager from the portal's Services page, navigate to your domain's document root, and upload the zip. Extract it there. If your local build lives in a subfolder like my-site/, make sure the contents land directly in the document root, not nested inside another folder.
For large media libraries, FTP is often faster and more reliable than a browser upload. Create credentials from the FTP Accounts tile in the portal and connect with any FTP client to transfer the wp-content/uploads folder directly.
Move the database
Export your local database as a .sql file using phpMyAdmin, Adminer, or whatever tool your local environment provides (Local, MAMP, and similar apps usually have a database export button built in).
On the live server, open phpMyAdmin from the portal (one-click login, no separate password needed), select the empty database you created earlier, and use Import to upload the .sql file. If the file is too large for a browser upload, split it into smaller files first.
Update wp-config.php in File Manager with the new database name, username, password, and host from the database you created. This is the step people forget, and it's why the site shows a database connection error immediately after moving files without touching the config.
Fix the URLs
Every local WordPress database has your local address (something like localhost:10003 or mysite.local) baked into post content, options, and serialized widget data. This is the step that actually makes the site work on the new domain.
A raw SQL UPDATE statement in phpMyAdmin's SQL tab breaks serialized PHP arrays (the ones storing widget settings and some plugin options), because the string length prefix no longer matches after the replace. A plugin like Better Search Replace (installed after the files are up, run once, then deleted) handles serialization correctly and does the job through wp-admin.
After the replace, log into wp-admin and check Settings → General. Confirm the WordPress Address and Site Address both show your live domain, not the local one.
Point DNS and let SSL issue
Once the site loads correctly under your temporary access (via IP or a local hosts-file edit), update your domain's nameservers or A record to point at Flashcloud. DNS records for the domain itself are edited under DNS Zone Editor in Services, not the Domains page (that one only controls nameservers).
Free SSL issues automatically about 5 minutes after DNS resolves to us, and renews on its own after that. Until DNS propagates fully, don't be alarmed by mixed results between devices. That's normal caching, not a broken migration.
After the move
Once the site is live, do a walkthrough: load the homepage, click through main navigation, submit any forms, and check that images render. If you run WooCommerce, test add-to-cart and checkout specifically.
From here, set up WordPress staging before your next big change. That's exactly the workflow staging is for, so future updates don't risk another round of broken-link cleanup. If the site feels sluggish after the move, run through My WordPress site is slow to rule out plugin bloat or unoptimized images carried over from local.
If you hit a database import that won't complete, a plugin conflict that only shows up on the live server, or you're not comfortable running the search-replace yourself, open a ticket from Support in the portal. It goes to a real person, not a bot, and they can walk through the database and file structure with you directly.