SiteGround's migration plugin handles file transfer and database import. It does not touch SSL certificates, email accounts, CDN origin records, or plugin license bindings — all of which are server-specific or externally managed. Missing any of these post-migration steps produces predictable failures: "Not Secure" warnings, email outages, broken media, and cache conflicts. For a site with standard complexity (15+ plugins, external CDN, premium licenses), expect 3–5 hours of post-migration work beyond what the plugin automates.

Check current SiteGround WordPress hosting pricing →

Who This Is For

This guide targets sysadmins, DevOps engineers, and WordPress developers responsible for migrating existing sites to SiteGround. It assumes working knowledge of DNS management, .htaccess configuration, and WordPress internals.

This guide applies if:

• You're migrating an existing WordPress site (any traffic level) with active plugins, external services, or domain-specific email
• You're running a WooCommerce, membership, or CRM-integrated site where post-migration downtime has direct revenue impact
• You're using an external CDN (Cloudflare, Fastly) or premium plugins with domain-tied licenses

This guide does not apply if:

• You're launching a new WordPress site on SiteGround — you'll configure these services from scratch, not re-configure them
• Your site has no external integrations, no domain email, and no CDN — in that case, the migration plugin covers most of the work, though a verification pass is still warranted

What the Migration Plugin Actually Handles

SiteGround's free WordPress migration plugin operates at the application layer. It transfers:

• The full WordPress file structure: themes, plugins, wp-content/uploads/, core files
• The complete MySQL database: posts, options, user data, plugin tables
• A temporary staging URL so you can verify the migrated site before DNS cutover

What it does not do: interact with server-level services, external DNS providers, certificate authorities, or third-party licensing APIs. The plugin has no awareness of your SSL certificate, your mail server configuration, your Cloudflare zone, or whether Elementor Pro's license is bound to a specific domain hash.

That boundary — application layer vs. everything else — determines exactly what breaks.

"Not Secure" Warning or Mixed Content Errors

What you'll see: Browser displays "Not Secure," or the page loads with missing assets and console errors like Mixed Content: The page was loaded over HTTPS, but requested an insecure resource.

Why it happens: SSL certificates are issued per-server. Your old certificate does not transfer. SiteGround provides free Let's Encrypt SSL, but it must be explicitly installed on the new server. Separately, WordPress stores siteurl and home in the database — if those values still reference http://, or if post content contains hardcoded http:// asset URLs, mixed content errors persist even after the certificate is installed.

Fix sequence:

1. Install SSL on SiteGround: Site Tools → Security → SSL Manager → select your domain → Let's Encrypt → Install. Completes in minutes.
2. Verify WordPress URLs: Settings → General. Both "WordPress Address (URL)" and "Site Address (URL)" must use https://.
3. Database search-replace for hardcoded HTTP paths:

   wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --precise --dry-run

   Run without --dry-run only after confirming the output. Always take a database backup first. WP-CLI targets serialized data correctly; GUI tools like Better Search Replace also work.
4. Force HTTPS via .htaccess: Add above the WordPress rules block in public_html/.htaccess:

   RewriteEngine On
   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   SG Optimizer can apply this automatically, but the manual rule is more reliable for edge cases.

Scope note: Sites with large media libraries or third-party embeds using absolute http:// paths make the database search-replace non-negotiable. Skipping it leaves broken assets scattered across post content, postmeta, and widget data.

Email Services Stop Working

What you'll see: Outbound email from the domain fails; incoming mail continues to arrive at the old server (or bounces if that server is decommissioned).

Why it happens: The migration plugin moves WordPress data, not mail server state. Email accounts, passwords, and mailbox contents live on the hosting server, not in the WordPress database. Your MX records still point to the old server. Once you cut DNS, incoming mail routes to SiteGround's mail infrastructure — but if you haven't recreated the accounts there, it has nowhere to deliver.

Fix sequence:

1. Recreate email accounts on SiteGround: Site Tools → Email → Accounts. Use identical usernames; assign new passwords and distribute them to account holders.
2. Update MX records: If DNS is managed at your registrar, update MX records to SiteGround's mail servers. If DNS is managed at Cloudflare or another external provider, update MX records there — SiteGround's A record change does not automatically update MX.
3. Migrate mailbox data if needed: For historical email, use IMAP-to-IMAP migration (imapsync or any mail client's import function). SiteGround supports cPanel-based email migration for some origin providers, but this is manual work for most setups.

Scope note: For any business running domain email, treat this as a blocking issue. Plan the email cutover explicitly — separate from the DNS cutover if possible — and notify affected users of credential changes before cutting over.

Review SiteGround's email and hosting features →

Images Missing or 404 on Media Assets

What you'll see: Images render as broken links; browser console shows 404s for URLs under /wp-content/uploads/.

Why it happens: Two causes are common. First, absolute image paths in post content reference the old domain or http:// — covered by the search-replace above, but worth isolating specifically for wp_posts and wp_postmeta. Second, WordPress's permalink rewrite rules are stored in .htaccess, which may not have been written correctly on the new server environment.

Fix sequence:

1. Confirm siteurl and home: Same check as the SSL fix. Wrong domain here breaks all absolute paths site-wide.
2. Database search-replace for media paths: If the domain changed (even protocol only), old paths like http://old-domain.com/wp-content/uploads/image.jpg resolve to 404. Run WP-CLI search-replace targeting both domain and protocol changes. The --precise flag handles serialized data in page builder tables.
3. Flush permalinks: Settings → Permalinks → Save Changes (click twice). This rewrites .htaccess with the correct rewrite rules for the current server. This single step resolves most 404s on post and page URLs that aren't related to domain changes.

Caching Conflicts with SG Optimizer

What you'll see: Pages load slowly, stale content persists after updates, or cache-clearing operations produce errors.

Why it happens: SiteGround installs SG Optimizer by default, which provides server-level caching (Dynamic Caching, Memcached, NGINX Direct Delivery). If the migrated site was running WP Super Cache, W3 Total Cache, WP Rocket, or similar, both systems attempt to cache simultaneously — resulting in double-caching, cache invalidation failures, or conflicting rewrite rules in .htaccess.

Fix sequence:

1. Deactivate and uninstall old caching plugins immediately after migration, before testing. Running two caching layers is not a performance hedge — it creates race conditions in cache writes.
2. Configure SG Optimizer: WordPress admin → SG Optimizer. Enable Dynamic Caching and Memcached. Enable CSS/JS minification and image optimization once the site is confirmed functional. Enable features incrementally so you can isolate any regressions.
3. Clear all caches: SG Optimizer → clear all, plus any external CDN cache purge. Test with a cache-busting query string (?nocache=1) to confirm origin response before validating cached delivery.

Scope note: Complex multisite setups or sites with aggressive custom caching rules may require .htaccess exclusions for specific paths. SG Optimizer's advanced settings support per-path cache exclusions.

External CDN Malfunctions (Cloudflare and Others)

What you'll see: Site is inaccessible through the CDN proxy, or CDN serves stale content indefinitely after migration.

Why it happens: CDNs operate as reverse proxies — they hold an origin IP that tells them where to fetch uncached content. Migration changes your server's IP. If the CDN's DNS A record still points to the old IP, it cannot reach SiteGround's servers. The CDN continues serving whatever it has cached (if anything) or returns errors.

Fix sequence:

1. Update DNS A record in the CDN dashboard: Cloudflare → DNS → update the A record to your SiteGround server IP. Find your SiteGround IP in Site Tools → Site → Information. Update AAAA if you're on IPv6.
2. Purge CDN cache: Force a full cache purge immediately after updating the origin IP. Otherwise the CDN may serve stale content for the duration of its TTL.
3. Verify propagation: Run dig yourdomain.com A or use a global DNS propagation checker to confirm the A record resolves to SiteGround's IP from multiple regions before declaring the cutover complete.

Scope note: If you're using Cloudflare Workers, custom WAF rules, or Transform Rules, verify each independently. The IP update resolves basic proxy connectivity, but custom logic tied to origin headers or response conditions may need re-validation.

Plugin License Invalidation

What you'll see: Premium plugins display license error messages, switch to reduced functionality, or stop processing (common with WooCommerce extensions and membership plugins).

Why it happens: Many premium plugins tie license validation to the domain name or an internal installation fingerprint. Some vendors include the server environment in that fingerprint. A server migration — even with the same domain — can trigger a license re-validation request that fails if the old installation is still marked active in the vendor's system, or if the plugin's internal site hash changed.

An important cross-referencing finding: Several WooCommerce extension vendors (including some in the WooCommerce.com marketplace) use a site URL hash combined with an active-installation count for license enforcement. If you validate the new installation before deactivating the old one, you'll hit the license seat limit — the new installation gets rejected even though the domain matches. Deactivate plugins on the source server before reactivating on SiteGround to avoid this.

Fix sequence:

1. Deactivate plugins on the source server first (if it's still accessible). This releases the license seat.
2. Deactivate and reactivate on SiteGround: For many plugins, this alone re-triggers license validation against the current domain.
3. Re-enter license keys: Go to each plugin's settings page and re-enter the license key. Some vendors require this step explicitly after any server change.
4. Contact vendor support if blocked: If the license system shows the old installation as active and you can't access the source server to deactivate it, the vendor's support portal can release the seat manually.

Scope note: Prioritize this check for e-commerce, membership, and CRM plugins. Functionality loss here has direct business impact. Run license validation during the staging phase (before DNS cutover) so you have time to resolve vendor tickets without user-facing downtime.

Time Allocation: What the Numbers Actually Look Like

For a WordPress site with approximately 500 media assets and 15 active plugins, the migration plugin handles the core transfer in roughly 20–40 minutes of automated processing. The manual steps above, done systematically and without unexpected complications, add approximately:

If any single item surfaces an unexpected issue — a license vendor's support queue, propagation delays, or a page builder's serialized data not updating cleanly — budget an additional 1–2 hours per incident. Sites migrated without this checklist commonly see 3–5 hours of reactive troubleshooting, concentrated in the first 24 hours post-cutover.

Final Recommendation

SiteGround's migration plugin is reliable for what it does: transferring files and the database. Treat everything else as manual work that needs to be planned before the DNS cutover, not discovered after.

Run this sequence:

1. Install SSL and verify HTTPS configuration on the staging URL (before DNS cutover)
2. Recreate email accounts and plan the MX cutover separately
3. Run database search-replace for domain/protocol changes
4. Deactivate conflicting caching plugins; configure SG Optimizer
5. Update CDN origin IP and purge cache
6. Validate premium plugin licenses on staging before going live

If your site has substantial plugin complexity or external service dependencies, allocate a full half-day for post-migration validation. That's a predictable cost. Skipping it makes the cost unpredictable.

Check current SiteGround WordPress hosting pricing →

Frequently Asked Questions

Related:

• SiteGround Hosting Plans Explained — what's included at each tier before you commit to a plan
• WordPress Hosting Comparison Guide — SiteGround vs. alternatives across performance, price, and support
• When SiteGround Is the Right Call — decision criteria for whether SiteGround fits your infrastructure requirements

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What breaks when you migrate WordPress to SiteGround?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SiteGround's migration plugin handles file transfer and database import. It does not touch SSL certificates, email accounts, CDN origin records, or plugin license bindings — all of which are server-specific or externally managed. Missing any of these post-migration steps produces predictable failures: \"Not Secure\" warnings, email outages, broken media, and cache conflicts. For a site with standard complexity (15+ plugins, external CDN, premium licenses), expect 3–5 hours of post-migration work b"
      }
    }
  ]
}
</script>

<!--PROCESSING_SUMMARY
Processed: siteground-wordpress-migration-guide.md
Output: siteground-wordpress-migration-guide.md
Site: OpsForge Labs
Category: guides
Article Type: TROUBLESHOOTING
AI Question: What breaks when you migrate WordPress to SiteGround?
Angle: SiteGround WordPress migration — automated vs. manual scope, with per-issue fix sequences
Cluster: siteground-wordpress
Prior Coverage: none
Action Needed - Affiliate Links: no — all resolved to /go/siteground-wordpress/
Hub Update Required: siteground-wordpress
HGD Blocks: n/a
Information Gain Source: WooCommerce extension license seat-limit behavior (deactivating old installation before activating new one to avoid rejection) — derived from cross-referencing WooCommerce.com marketplace license enforcement documentation and vendor support patterns reported in WooCommerce community forums
END_PROCESSING_SUMMARY-->