What Website Files Do You Need to Migrate to a Different Hosting Provider?
Switching hosting providers sounds straightforward — but it's easy to leave something behind. A successful migration means identifying every file type your site depends on, not just the ones you can see in a browser. Here's what actually lives on a web server, why each piece matters, and what shapes the complexity of any given move.
Why Website Migration Is More Than Copying a Folder
A website isn't a single file — it's a collection of files, databases, configurations, and environment settings working together. When you move to a new host, you're recreating that entire environment. Miss one component and your site may load broken, lose data, or fail entirely.
The good news: once you understand what the components are, migration becomes a checklist problem rather than a mystery.
The Core File Types to Migrate
Static Files (Your Website's Visual Layer)
These are the files a browser directly reads and renders:
- HTML files — the structure and content of each page
- CSS files — stylesheets that control layout and appearance
- JavaScript files — client-side interactivity and logic
- Images, video, and audio — media assets stored in formats like
.jpg,.png,.webp,.mp4,.svg - Fonts — custom typeface files, often
.woffor.woff2format - Favicon and manifest files — browser tab icons and progressive web app settings
For a static site (no backend, no database), this category is essentially the entire migration.
Server-Side Application Files
If your site runs on a CMS like WordPress, or uses a backend language like PHP, Python, or Node.js, you'll also have:
- PHP, Python, Ruby, or Node.js files — the logic that generates pages dynamically
- Template and theme files — the layout files your CMS uses to render content
- Plugin and extension files — third-party add-ons stored in directories like
/wp-content/plugins/ - Configuration files — settings files like
wp-config.phpor.envthat connect your app to its database and define environment variables 🔑
Configuration files are easy to overlook and critical to include. They often contain database credentials and API keys — handle them carefully and never expose them publicly.
The Database
Most dynamic websites — WordPress, Drupal, Magento, custom apps — store their actual content in a database, not in flat files. The files on the server are the engine; the database holds the fuel.
Common database types include MySQL, MariaDB, and PostgreSQL. You'll typically export this as a .sql dump file and import it at the new host.
What lives in the database varies by platform, but generally includes:
- Blog posts, pages, and product listings
- User accounts and comments
- Settings and plugin configuration data
- Navigation menus and widget settings
Without the database, the application files alone produce an empty or broken site.
Media Uploads
In CMS platforms, user-uploaded media (images, PDFs, documents) are stored separately from core application files — often in a dedicated directory like /wp-content/uploads/ in WordPress. These can grow large over time and are frequently skipped in partial migrations. A site with missing media will show broken image icons across every affected page.
Server Configuration Files
These files control how the web server itself behaves:
.htaccess(Apache servers) — handles URL redirects, rewrite rules, access control, and caching headersnginx.confor site-specific config blocks (NGINX servers) — similar role to.htaccessbut managed differentlyrobots.txt— tells search engine crawlers which pages to indexsitemap.xml— helps search engines discover all pages on your site
Losing .htaccess is a common migration mistake. It often contains the permalink rules that make clean URLs work — without it, most pages on a WordPress site will return 404 errors.
Variables That Affect Migration Complexity
| Factor | Low Complexity | High Complexity |
|---|---|---|
| Site type | Static HTML | CMS or custom app |
| Database | None | Large, complex schema |
| Media library | Small | Thousands of files, GBs of data |
| Email hosting | Separate provider | Hosted with the website |
| SSL certificate | Transferred automatically | Must be reissued/reconfigured |
| Custom server config | Minimal | Complex rewrites, cron jobs |
| Subdomains/subfolders | None | Multiple environments |
What Often Gets Left Behind 🗂️
Even experienced developers sometimes miss:
- Cron jobs — scheduled server-side tasks that run automatically (database cleanups, email queues, backups)
- Email accounts and mail data — if your email lives on the same host as your website, migrating the site doesn't automatically move the mailboxes
- SSL/TLS certificates — a certificate issued by one host doesn't travel with you; you'll need a new one on the new server
- Subdomains — separate subdomain configurations may need to be recreated independently
- Environment variables — API keys, payment gateway credentials, and third-party service tokens set at the server level rather than in a config file
How Your Setup Determines the Scope
A simple brochure site built with static HTML might migrate in minutes — compress the files, upload them, done. A mature e-commerce store running on a custom stack could involve coordinating a database freeze, a file transfer, a DNS cutover window, and post-migration testing across multiple environments.
The same checklist applies in both cases, but the stakes and time involved are completely different. Managed hosting platforms sometimes offer migration tools or white-glove services that handle most of this automatically — but understanding what's being moved is still valuable, especially when verifying that nothing was missed after the switch.
The right approach to your migration depends on what your site is built on, how large it's grown, and how much downtime you can tolerate during the transition — and those answers look different for every site.