This guide helps you migrate your WordPress site from other CDN and security services (like Cloudflare, Sucuri, JetPack, etc.) to Pressidium EDGE.

Migrating from another service to EDGE involves:

  1. Pre-Migration Planning: Understanding your current setup
  2. EDGE Setup: Setting up EDGE for your site
  3. DNS Migration: Switching DNS from old service to EDGE
  4. Verification: Ensuring everything works correctly
  5. Cleanup: Removing old service configuration

Your account and website must be provisioned on Pressidium’s EDGE network. If your account is still on the Pressidium Advanced Network, follow Upgrade your account to Pressidium EDGE before continuing.

Pre-Migration Planning

Understand Your Current Setup

Before migrating, document your current configuration:

  1. Current Service:
    • Which service are you using? (Cloudflare, Sucuri, etc.)
    • What features are you using?
    • Are there any service-specific considerations?
  2. DNS Configuration:
    • Where is DNS currently managed?
    • What DNS records are in place?
    • Are you using the service’s nameservers or DNS records?
  3. SSL Certificate:
    • How is SSL currently configured?
    • Is SSL provided by the service?
    • Any SSL migration considerations?
  4. Caching Configuration:
    • What caching is configured?
    • Any cache rules or exclusions?
  5. Security Settings:
    • What security features are enabled?
    • Any custom WAF rules?
    • IP whitelists/blacklists?

Migration Checklist

Before starting migration, confirm that:

  • [ ] Current configuration is documented
  • [ ] Backup of WordPress site is created
  • [ ] DNS records are documented
  • [ ] Security settings are documented
  • [ ] Scheduled the migration timing
  • [ ] Cache rules are documented (if applicable)
  • [ ] Pressidium account is created

Migration from Cloudflare

Cloudflare can act as both the authoritative DNS provider and the reverse proxy. You can stop using the Cloudflare proxy while continuing to use Cloudflare DNS.

Before the cutover

  1. Export the DNS zone from DNS > Records > Import and Export, or save a complete copy of the records.
  2. Document the Cloudflare settings that affect the site, including:
    • SSL/TLS mode and HTTPS redirects
    • Cache Rules and legacy Page Rules
    • WAF custom rules and IP access rules
    • Redirect or Transform Rules
    • Workers or other edge logic
    • Load balancing or origin-routing behavior
  3. Identify the proxied A, AAAA, and CNAME records used by the website.
  4. Document any Cloudflare WordPress plugin or API integration used for cache clearing or configuration.

Cloudflare rules and Workers are not imported into EDGE. Recreate supported behavior manually and review unsupported custom logic before cutover.

Cut over from the Cloudflare proxy

  1. Keep the domain on its existing Cloudflare nameservers unless you also intend to move DNS hosting.
  2. In DNS > Records, replace the website’s existing A, AAAA, or CNAME values with the records shown in the Pressidium Dashboard.
  3. Set every EDGE verification and traffic-routing record to DNS only so Cloudflare does not proxy traffic in front of EDGE.
  4. Remove conflicting records for the same hostname.
  5. Verify the records in the Pressidium Dashboard.

A Proxied Cloudflare record keeps Cloudflare in the HTTP and HTTPS request path. A DNS only record returns the configured EDGE destination without routing the request through Cloudflare.

After verification

  • Keep Cloudflare if you still use it as your authoritative DNS provider.
  • Remove or deactivate Cloudflare-specific WordPress plugins only when they are no longer required.
  • Revoke API tokens that were used only for the old proxy or cache configuration.
  • Remove the domain from Cloudflare only after moving the complete DNS zone to another provider and changing the authoritative nameservers.

Common Cloudflare migration issues

  • The EDGE records are still set to Proxied instead of DNS only.
  • An old A, AAAA, or CNAME record conflicts with the new EDGE record.
  • Only some of the displayed A or AAAA records were added.
  • Domain verification records are proxied or were added to the wrong DNS zone.
  • A Cloudflare Worker, redirect, or transformation rule is still changing requests.
  • DNS propagation is incomplete.

Migrate from Sucuri Website Firewall

Sucuri Website Firewall normally routes a website through the Sucuri network by pointing its DNS A record to a Sucuri firewall IP address.

Before the cutover

Document:

  • The current Sucuri firewall IP
  • Cache settings and cache exceptions
  • IP allowlist and blocklist entries
  • Country, URL, user-agent, cookie, and protected-page rules
  • SSL mode and any custom certificate configuration
  • Origin and backup-origin settings
  • The Sucuri WordPress plugin features in use

Sucuri does not provide a universal one-click export for all firewall settings. Save the relevant values and screenshots manually.

Cut over from Sucuri

  1. Prepare and verify the domain in Pressidium EDGE.
  2. At the active DNS provider, replace the A record pointing to the Sucuri firewall IP with the CNAME or complete A and AAAA record set shown in the Pressidium Dashboard.
  3. Remove conflicting website-routing records.
  4. Wait for propagation and verify the domain in the Dashboard.
  5. Test the site and its important dynamic functionality.

After verification

  • Disable the Sucuri firewall service only after DNS no longer routes traffic through it.
  • Clear the Sucuri cache before deactivation when you want a clean rollback point.
  • Deactivate or remove the Sucuri WordPress plugin only after reviewing the features you still use. The plugin may provide local scanning, hardening, monitoring, or alerts that are separate from the external firewall.
  • Cancel or reduce the Sucuri subscription through the Sucuri account process after confirming the service is no longer active for the site.

Common Sucuri migration issues

  • The domain still resolves to the Sucuri firewall IP.
  • A backup or www hostname still points to Sucuri.
  • Old Sucuri cache or WordPress integration settings remain active.
  • Access-control rules were not recreated in EDGE.
  • A protected page or third-party service is blocked after the change.

Migrate from Jetpack

Jetpack normally operates through WordPress rather than by placing the full website behind a DNS reverse proxy. In most cases, there is no Jetpack-specific DNS cutover.

Jetpack includes many features that do not overlap with EDGE. Keep the plugin when you still use features such as backups, activity logs, Stats, Search, Social, forms, or other WordPress.com services.

Identify overlapping features

Review whether the site uses:

  • Site Accelerator or Image CDN, previously called Photon
  • Asset CDN
  • Jetpack Boost Image CDN
  • Jetpack Boost CSS or JavaScript concatenation
  • Lazy loading or image optimization
  • Brute-force protection
  • Jetpack Firewall or Jetpack Protect

Disable overlapping features safely

  1. Confirm that the site is already serving traffic through EDGE.
  2. Open Jetpack > Settings, Jetpack > Boost, or the Jetpack modules page.
  3. Disable one overlapping performance or security feature at a time.
  4. Clear the applicable caches.
  5. Test images, galleries, CSS, JavaScript, login, forms, and dynamic pages after each change.
  6. Keep all Jetpack features that still provide required functionality.
  7. Deactivate the Jetpack plugin only when no remaining Jetpack feature is needed.

After disabling Jetpack’s image delivery features, check the browser’s Network panel for assets that still load from Jetpack CDN hostnames such as i0.wp.com, i1.wp.com, or i2.wp.com. Some Jetpack blocks or features may continue to use the Image CDN and should be tested separately.

Migrate from another CDN or reverse proxy

Use the following process for services such as KeyCDN, Bunny CDN, Fastly, Akamai, or another CDN, proxy, or security network.

Document the current setup

Record:

  • Website-routing A, AAAA, and CNAME records
  • Dedicated CDN hostnames and asset URL rewriting
  • Pull-zone or origin configuration
  • Cache rules, exclusions, and TTLs
  • SSL certificates and HTTPS behavior
  • Redirect, header, edge-function, or request-transformation logic
  • Firewall and access-control rules
  • Origin allowlists and trusted proxy IP ranges
  • Cache-purge plugins, APIs, and deployment hooks
  • Log, analytics, or alert integrations

Cut over

  1. Prepare the domain and certificate in EDGE.
  2. Recreate required cache exclusions and supported access rules.
  3. Replace the old provider’s website-routing records with the values displayed in the Pressidium Dashboard.
  4. Disable proxying at the DNS provider when another proxy would otherwise remain in front of EDGE.
  5. Remove asset URL rewriting only after confirming assets load correctly from the primary site hostname.
  6. Verify the full website before deactivating the old service.

The exact removal procedure depends on the previous provider. Keep the account active until traffic has moved to EDGE and you have confirmed that no plugin, deployment process, or application setting still depends on it.

Roll back the migration

Use the rollback copy of your previous DNS configuration if the site cannot operate correctly through EDGE.

  1. Restore the previous website-routing A, AAAA, or CNAME records at the active DNS provider.
  2. Restore the previous proxy status where required.
  3. Re-enable any plugin or integration disabled during cleanup.
  4. Wait for DNS propagation.
  5. Clear the applicable old-provider and WordPress caches.
  6. Confirm that the site is again loading through the previous service.
  7. Investigate the EDGE configuration before scheduling another cutover.

Do not restore or change unrelated email and verification records.

Common issues and solutions

Domain verification remains pending

Check that the verification record type, host, and value match the values shown in the Pressidium Dashboard. Confirm that the record is in the active DNS zone and is not proxied by another service.

The site still uses the previous provider

Check the domain from multiple DNS resolvers. Old records may still be cached, or another hostname may still point to the previous service. Confirm which nameservers are authoritative and make sure you edited the correct DNS zone.

SSL is pending or the browser shows a certificate warning

Complete domain-ownership verification before routing traffic. Confirm that every public hostname is mapped in Pressidium, covered by a certificate, and pointed to the EDGE records shown in the Dashboard.

The site loads, but images or styles are broken

Check for hardcoded CDN hostnames, WordPress plugins that rewrite asset URLs, mixed-content requests, stale HTML, or vendor-specific optimization rules. Disable URL rewriting only after confirming the primary asset URLs work.

WordPress admin, login, cart, or checkout behaves incorrectly

Review cache exclusions and cookies. Dynamic and user-specific pages must not be cached like public pages.

Updated content is not visible

Clear the previous service cache before deactivation, then clear the applicable Pressidium caches. Open the page in a private browser window to rule out local browser cache.

Use Manage Website Caches to clear Page Cache, CDN Cache, or all active caches.

A legitimate user or service is blocked

Review the IP Blocklist, IP Allowlist, and Geo-blocking settings. Remove an incorrect rule or add a verified trusted address where appropriate.

Need help?

Contact Pressidium Support if:

  • You are unsure which records from the previous service must be replaced
  • Domain verification or SSL remains pending after the records are publicly visible
  • The site does not load correctly after DNS propagation
  • A custom cache, firewall, redirect, or edge rule does not map directly to the available Dashboard controls
  • A legitimate visitor, administrator, payment service, or integration is blocked

Include:

  • The Pressidium website name and affected domain
  • The previous CDN or security provider
  • The active DNS provider
  • The previous and current website-routing records
  • Screenshots of the DNS records and Dashboard status
  • The date, approximate time, and timezone of the cutover
  • The exact browser or Dashboard error
  • The pages, services, or user flows affected
  • The troubleshooting steps already completed

Do not include passwords, API secrets, certificate private keys, or other sensitive credentials.

Pressidium Support can help review the EDGE configuration and DNS values. Changes to third-party subscriptions, accounts, or provider-specific settings remain under your control.

Where to go next