Migrating WordPress to Next.js in Costa Rica — 2026 Guide

Costa Rica is full of WordPress sites loading in 8 seconds and paying USD 120/month for shared hosting that still throws 504 errors. When a client asks "should we migrate to Next.js?", the answer is not always yes — but when it is, monthly savings pay back the migration in less than 18 months and organic traffic climbs. This guide gives you the criteria to decide, real USD cost ranges, and the seven steps to migrate without Google penalizing you.

If your PageSpeed is below 50, you have been hacked in the last year, or you pay more than USD 80/month in plugins + hosting, there is a high chance migrating is worth it. If your WordPress site loads fast and has low traffic, probably not.

💡 TL;DR: Migrating WordPress to Next.js costs USD 1,800–6,500 in CR. Worth it when PageSpeed < 50, recurring hacks, or paying > USD 80/month in plugins. With properly built 301 redirects, traffic GOES UP 15–40% in 3 months due to Core Web Vitals improvement.

Why people want to leave WordPress

WordPress powers 43% of the web. For many sites it is still the right choice. But three reasons we see clients fleeing in 2026:

1. Performance. The problem is not WordPress itself, it is the combination WordPress + plugins + premium theme + shared hosting. Every plugin adds scripts, every theme loads libraries you do not use, shared hosting splits resources across hundreds of sites. Result: PageSpeed below 50 on mobile, Core Web Vitals in red, Google dropping you in rankings since 2021.

2. Security. WordPress is the #1 target of automated bots. Every outdated plugin is a door. A client got hacked through a form plugin not updated since 2022 — they paid USD 1,500 in "cleanup." Another had a brute-force that took down the site for 3 days during peak season. Hacks are routine.

3. Rising costs. A professional WordPress site pays for: hosting (USD 30–80/month), Yoast Premium (USD 99/year), Elementor Pro (USD 59/year), WP Rocket (USD 59/year), Wordfence (USD 119/year), backups (USD 100/year), SSL + domain. Total: USD 80–200/month recurring — USD 2,880–7,200 over 3 years. Without counting team time fixing plugin conflicts after every major update.

When NOT to migrate

Migrating is not an automatic upgrade. There are cases where it is overkill and just costs you money:

• Your WordPress site loads well. PageSpeed > 80 on mobile, Core Web Vitals green, response in < 2 seconds. Nothing to gain in performance.
• You have low traffic (< 5,000 visits/month). Recurring costs are manageable and the USD 2,500 investment only pays back if it converts into more leads. ROI takes years.
• You depend on a plugin with no Next.js equivalent. Heavy LMS (LearnDash), complex memberships (MemberPress with hundreds of levels), marketplaces (WC Vendors). Migrating can take 16+ weeks and cost USD 12,000+.
• Content is edited by a non-technical team comfortable with Gutenberg. A headless CMS has a learning curve. If your 5-person team edits posts without help, the organizational cost matters.

Middle-ground solution: if your problem is only performance, optimize WordPress instead of migrating. Decent hosting (Kinsta, WP Engine) + aggressive cache (WP Rocket, Cloudflare) + plugin purge + WebP costs USD 300–800 and can raise PageSpeed from 35 to 75.

When YES to migrate

The three main triggers we see in clients who migrate with good ROI:

1. Sustained PageSpeed below 50. If you exhausted all WordPress optimizations (cache, optimization plugins, CDN, premium hosting) and you are still below 50 on mobile, the problem is structural. WordPress loads ~80–150 KB of extra JavaScript just for admin bar, jQuery, widgets and plugin scripts. Next.js starts from zero — only loads what your site needs. We see jumps from 35 to 95 consistently.

2. Recurring security hacks. If you have been hacked more than once in 24 months, or if you pay a "security" retainer and it still happens, the problem is the attack surface inherent to WordPress (PHP, public MySQL, unaudited third-party plugins). Next.js + Vercel drastically reduces that surface.

3. Rising recurring costs. If you pay > USD 80/month in hosting + plugins and plan to grow, those costs only go up. Every new plugin is another license, every traffic upgrade is a more expensive plan. In Next.js, hosting scales with real traffic.

Combos that almost always justify migrating: PageSpeed < 50 + > 30,000 organic visits/month; recent hack + active ecommerce; premium plugins > USD 150/year + plan to grow.

Comparative costs: WordPress vs Next.js

Three real scenarios we see quoting in Costa Rica. All in USD and at 3 years so the accumulated impact is visible.

Scenario 1: small corporate site (10–20 pages + blog)

WordPress (3 years of operation)

Next.js + Vercel (3 years of operation)

3-year savings: USD 1,925. And that is without counting your team's maintenance time, the cost of a potential hack, or lost sales from slow loading. Want the exact range for your site? Use the quote builder — 4 questions, 30 seconds.

Scenario 2: medium site with light ecommerce (WooCommerce)

WordPress + WooCommerce with decent plugins (skimping on plugins in ecommerce is the worst false economy): USD 200–280/month recurring. Over 3 years: USD 7,200–10,000 + USD 3,000 initial development = USD 10,200–13,000.

Next.js with Shopify as backend or Medusa: USD 50–80/month (Shopify Lite + Vercel Pro). Over 3 years: USD 1,800–2,880 + USD 5,500 migration = USD 7,300–8,380.

3-year savings: USD 2,900–4,600. And conversion goes up due to faster checkout (Stripe checkout on Next.js converts 12–18% more than WooCommerce with slow plugins, based on data from our migrating clients). For the custom-vs-Shopify decision, see our comparison at /comparar/custom-vs-shopify.

Scenario 3: large site with high traffic (50,000+ visits/month)

At this level WordPress starts to hurt. Hosting that holds without crashing costs USD 150–300/month (WP Engine Growth, Kinsta Business), premium plugins are USD 500+/year, and you will still have spikes that take down the site on Black Friday.

Professional WordPress with CDN, WAF and monitoring: USD 350–500/month = USD 12,600–18,000 over 3 years.

Next.js + Vercel Pro: USD 80–200/month based on usage = USD 2,880–7,200 over 3 years, + USD 6,500 initial migration = USD 9,380–13,700.

3-year savings: USD 3,220–8,620, plus real zero downtime (Vercel tracks 99.99% uptime vs ~99.5% typical of WordPress shared hosting — that is 8 more hours of uptime per month worst-case).

The critical part: preserving SEO

This is where most migrations die. I have seen sites lose 70% of their organic traffic in 30 days due to a badly executed migration. The causes are almost always the same.

URLs: rule number one

Keep the same URLs. If Google indexed /blog/how-much-software for 18 months and built authority there, do not change it to /articles/how-much-software just because you like the new structure better. Every URL that changes without a perfect 301 redirect loses 100% of its SEO.

If you MUST change URLs (because the new structure is objectively better, or because WordPress generated ugly URLs with ?p=123), then every old URL must have a 301 redirect to its new location. No exceptions.

301 redirects: how to do them right in Next.js

In next.config.js:

module.exports = {
  async redirects() {
    return [
      {
        source: '/blog/old-url',
        destination: '/blog/new-url',
        permanent: true, // emits 301, not 302
      },
      // ... hundreds more
    ]
  },
}

For large migrations, the pattern is to generate the redirects array from a CSV exported from WordPress + the new inventory, not write them by hand. Verify each with curl -I https://your-site.com/old-url before launch — it should respond 301 with the new URL in the Location header.

Common mistakes:

• Using permanent: false (which emits 302) — that tells Google "do not consolidate SEO on the new URL." Kills SEO.
• Redirect chains (URL A → URL B → URL C). Every hop loses 5–10% of link juice. Always map directly to the final destination.
• Redirects with loops (rare but it happens). Verify no redirect points to a URL that also redirects.
• Forgetting the trailing slash. /blog/post/ and /blog/post are different URLs for Google. Decide which to use and redirect the other.

Sitemaps and robots.txt

Generate the dynamic sitemap.xml in Next.js (there is a standard pattern with app/sitemap.ts). Include ALL public URLs of the new site, with correct lastmod. Submit it to Google Search Console on launch day.

robots.txt: check that you do NOT accidentally block site sections (a typical mistake is leaving the Disallow: / you had on staging). Include the sitemap reference: Sitemap: https://your-site.com/sitemap.xml.

Meta tags and schemas

Every page of the new site must have:

• <title> equal or better than in WordPress
• meta description word-for-word (Yoast saves this in the database — export it)
• Complete Open Graph (og:title, og:description, og:image, og:type)
• Twitter Card
• BlogPosting schema for posts, Organization for the site, FAQPage if it has FAQ
• Canonical URL pointing to itself

If you lose the meta description during migration, Google will generate an automatic one that is probably worse — and CTR drops. It is the difference between the migration lifting traffic 30% or dropping it 10%.

Real case: marketing agency in San José

A marketing agency in San José had an 8-page WordPress site + blog with 40 posts. They had been with it for 4 years. PageSpeed mobile: 38. They paid USD 110/month in hosting + plugins. The site went down 2–3 times a month due to some plugin fighting with another after automatic updates.

We migrated it to Next.js + Payload CMS. 8 pages rebuilt pixel-by-pixel (no visible change), 40 blog posts migrated with all URLs intact, BlogPosting schemas added (they did not have them), contact form connected directly to HubSpot (before they had Contact Form 7 + Zapier + an ugly workaround).

Results at 3 months post-launch:

• PageSpeed mobile: 38 → 95
• Largest Contentful Paint: 4.8s → 0.9s
• Organic traffic: +32% (without changing content)
• SERP positions on main keywords: +5 to +12 positions on average
• Blog page load time (Time to First Byte): 1.2s → 180ms
• Monthly costs: USD 110 → USD 0 (fits in Vercel Hobby)
• Downtime: 2–3 crashes/month → 0 crashes in 90 days

Migration cost: USD 1,800. Timeline: 3 weeks. ROI break-even: 16 months (just from recurring savings, not counting the lead increase).

This case is also referenced in the pillar article about how much software costs in Costa Rica.

Seven steps to migrate without losing SEO

This is the process we follow in every migration. If you do it by hand (or with another agency), ask them to follow something similar.

Step 1: Audit the current site and export the full inventory

Before touching anything, document what you have. Tools:

• Screaming Frog (free up to 500 URLs): gives you the complete URL listing, status codes, meta tags, schemas, images with alt text.
• Google Search Console: organic traffic, top queries, CTR, indexing errors.
• Google Analytics: users, sessions, top pages, conversions.
• Ahrefs / SEMrush: important backlinks, authority of each URL.

Export everything to CSV. This snapshot is your baseline. Without it, you cannot tell if the migration lifted or dropped traffic.

Step 2: Define the new URL architecture

Ideally: identical to the current one. If you must change something, plan it now. Document every change in a CSV with two columns: old_url, new_url. This CSV is the input for the redirects later.

Step 3: Migrate content to a headless CMS or markdown

Decide the storage:

• Markdown in git (fastest, ideal for blogs with < 200 posts): export from WordPress via REST API, convert to markdown with a script (there are ready templates), commit to git.
• Payload CMS (recommended for more dynamic sites): exposes REST/GraphQL API, WordPress-like admin UI, self-hosted on Railway or Vercel.
• Sanity / Strapi: if the content team needs complex workflow (review, scheduling, multi-language).

Preserve all fields: body, author, original date (publishedAt), update date (updatedAt), categories, tags, meta description, OG image, custom schema if you had it.

Step 4: Build the Next.js site with feature parity

It is not just replicating the design. Make sure you have:

• Dynamic sitemap.xml (app/sitemap.ts)
• Correct robots.txt
• RSS feed (if your site had an active blog)
• Schemas (BlogPosting, Organization, FAQPage)
• hreflang if multi-language
• Image lazy loading (Next.js Image component does it by default)
• Working forms (Resend for email, or webhook to your CRM)
• Analytics (GA4, Plausible) connected

If you had calendar plugins, complex forms, memberships, that is solved with new code — not plugins. To decide which stack to use (Next.js vs Astro vs Remix), read how to pick stack in 2026.

Step 5: Configure 301 redirects for every URL that changed

In next.config.js, in the redirects() array, add every old_url → new_url pair with permanent: true. For large sites, generate the array programmatically from the CSV in step 2.

Verify before launch:

curl -I https://staging.your-site.com/old-url
# Must respond: HTTP/2 301
# And a header: Location: https://staging.your-site.com/new-url

Step 6: Launch, regenerate the sitemap, and notify Google

Launch day:

1. Point the domain to the new Vercel deploy (DNS change — takes 1–24 hours to propagate).
2. Once propagated, verify with curl -I a couple of random URLs to confirm the new site responds.
3. Go to Google Search Console → Sitemaps → submit the new sitemap.xml.
4. Go to URL Inspection for your top 20 pages → request indexing of each.
5. Monitor the error log in Search Console for the next 72 hours. Watch for:
   • Unexpected 404s
   • Redirect chains
   • Canonical issues
   • Sharp drop in impressions

Step 7: Monitor for 90 days and adjust what fails

The first 4 weeks you will see fluctuations — Google is re-indexing, re-evaluating authority, adjusting ranking. It is normal. What matters: overall trend.

Review weekly:

• Search Console: coverage errors, Core Web Vitals, impressions, CTR.
• GA4: organic traffic vs baseline, top landing pages.
• Ahrefs/SEMrush: positions of your top 20 keywords.

If a specific URL loses more than 30% of sustained traffic at 4 weeks, investigate:

• Is the 301 redirect properly configured?
• Is the content identical to WordPress?
• Was the meta description preserved?
• Are there schema errors?
• Does the page load fast?

90 days after launch, you should see organic traffic equal to or greater than baseline. If it climbed 15–40%, that is typical — the Core Web Vitals improvement pushes you up in SERPs.

Common mistakes in failed migrations

These are the mistakes we see repeatedly in migrations that come to us for "rescue" (yes, that happens — clients who migrated with another vendor and lost 50% of traffic come asking us what to do).

1. Not keeping URLs. The #1 by far. The agency decides to redesign the URL architecture "because the current one is ugly" and does not set up redirects. 100% of SEO is lost.

2. Redirect chains. Old URL → intermediate URL → final URL. Every hop loses authority. Always map directly to the final URL.

3. Forgetting the meta description. If Yoast had custom meta descriptions and the migration loses them, Google generates worse automatic ones. CTR drops, traffic drops.

4. Not regenerating the sitemap. The old sitemap points to URLs that no longer exist. Google gets confused, marks the site as "low quality," lowers ranking.

5. Accidentally blocking the new site in robots.txt. It happens more than you would think. The migration is done in staging with Disallow: / and no one removes it on production. Google stops indexing everything.

6. Not having a pre-migration baseline. Without a baseline, you do not know if the migration lifted or dropped traffic. And if it dropped, you do not know by how much. Unforgivable.

7. Launching on a Friday night. If something fails, there is no team on Saturday to fix it. Launch Tuesday morning — maximum business hours afterward to fix whatever comes up.

8. Not testing mobile. WordPress + premium theme looks "ok" on mobile because the theme handles it. Custom Next.js can break on mobile if you do not test it. PageSpeed mobile, Core Web Vitals mobile, and real test on physical device, not just the browser inspector.

9. Migrating content by hand when there are > 50 posts. Every manual post has risk of error (losing date, losing author, losing a schema). Use scripts. It takes a week to automate the migration for 200 posts vs. two weeks to do it by hand with errors.

10. Not considering images. WordPress serves images from /wp-content/uploads/. If those URLs change, all images embedded in old posts break. Keep the paths or set up a temporary proxy while posts are edited.

In summary

Migrate when: PageSpeed < 50, recurring hacks, costs > USD 80/month, plan to grow.

Do not migrate when: site loads well, low traffic, depends on very specific plugins, non-technical team tied to Gutenberg.

If you are unsure whether your case is worth it, write to us. The initial quote is free and we will honestly tell you whether migrating makes sense or whether we recommend optimizing what you already have (sometimes that is what the client needs to hear — and we tell them).

💡 For an approximate quote in 30 seconds, use the interactive quote builder. 4 questions → USD range + WhatsApp message with your scope pre-filled.

📞 To talk directly: WhatsApp +506 8433 7752 or admin@siriusx.net. Monday to Friday 8am–5pm, Saturdays 8am–12pm, CR time.

Related posts

• How much does software cost in Costa Rica — real USD ranges by project type and vertical.
• Next.js, Astro, or Remix: how to pick stack in 2026 — technical decision to keep budget in check.