Skip to main content

i18next alternatives: a migration buyer's guide

· 10 min read
Arnaud Ambroselli
Founder of i18n-keyless

If you've already decided i18next isn't the right fit, the question isn't whether to migrate — it's what to migrate to. The answer depends on what's actually painful about your current setup, how much migration budget you have, and what your team's localization workflow looks like.

This guide is a decision framework for picking the destination.

TL;DR​

Pick based on what's painful right now:

What's painfulMove to
Key management overheadi18n-keyless (no keys at all)
Translation team can't access stringsLokalise or Crowdin (TMS)
Need ICU plural rules + want better DX than i18nextreact-intl or Lingui
Want in-context editing for non-engineersTolgee
On Next.js and want native integrationnext-intl
Complex enterprise localizationPhrase or Smartling

The detailed roundup is in best i18next alternatives in 2026. This article is about the migration question: cost, dual-run strategy, and how to budget the move.

Step 1: Diagnose what's actually painful​

The most common reasons teams leave i18next, in order of frequency:

  1. "We waste hours on key management." Naming keys, refactoring keys, syncing locale files, missing-key bugs. → i18n-keyless directly removes this pain.

  2. "Our translators can't easily access strings." Engineers send JSON files; translators struggle with context; round-trips are slow. → A TMS (Lokalise, Crowdin) is the right move, not a different library.

  3. "We've outgrown the simple i18next setup and need TMS features." Glossaries, translation memory, screenshots. → Lokalise or Crowdin.

  4. "i18next's bundle size / runtime cost is too much." Some teams need a leaner library. → Lingui or next-intl have smaller footprints.

  5. "Our developer experience is bad and we'd ship faster with less i18n ceremony." → i18n-keyless or Lingui.

  6. "We need first-class Next.js App Router support." → next-intl.

If your reason isn't on this list, write it down explicitly. The migration target depends on the specific pain — not on a generic "i18next is bad" sentiment (it isn't).

Step 2: Match pain to destination​

Pain: key management overhead​

Move to: i18n-keyless. This is the only option that fully removes keys. Lingui and Tolgee make keys nicer; they don't remove them.

  • Setup cost: ~5 minutes.
  • Migration cost: 1–3 sprints depending on app size (see migration guide).
  • Ongoing cost: roughly token-based, scales with translation volume.
  • Downside: limited ICU plural rules, depends on a hosted backend.

Pain: translators need a workflow​

Move to: Lokalise (commercial), Crowdin (open-source / community), or Phrase (enterprise).

  • Setup cost: hours-to-days to wire up the CLI and CI integration.
  • Migration cost: low if you keep i18next as the runtime client (most teams do this — TMS sits above the library, not in place of it). The TMS pushes locale files; i18next reads them. Same pattern, just better translator UX.
  • Ongoing cost: TMS subscription + translator costs.
  • Downside: TMS adds operational complexity if you don't use the features.

Important: moving to a TMS isn't actually leaving i18next. You'd typically keep i18next as the client library and put a TMS in front of it. The decision is "do we add a TMS layer," not "do we replace i18next."

Pain: ICU MessageFormat​

Move to: react-intl or Lingui. Both have full ICU support and better DX than i18next's plural handling.

  • Setup cost: similar to i18next.
  • Migration cost: medium — replace t() calls with <FormattedMessage> (react-intl) or <Trans> (Lingui). Re-key existing translations.
  • Ongoing cost: similar.
  • Downside: still key-based, still locale files to maintain.

If keys are the actual pain and ICU is the secondary concern, i18n-keyless with explicit branching is often acceptable — see how plurals work in the i18next migration guide.

Pain: in-context editing for non-engineers​

Move to: Tolgee. It's the only solution with first-class in-context editing.

  • Setup cost: ~1 hour for the cloud version, more for self-hosted.
  • Migration cost: medium — Tolgee is key-based, so you re-key from i18next to Tolgee's format.
  • Ongoing cost: subscription + dashboard hosting if self-hosted.
  • Downside: smaller community, still key-based.

Pain: Next.js App Router specifically​

Move to: next-intl. Purpose-built for Next.js with server components support.

  • Setup cost: ~30 minutes.
  • Migration cost: medium — re-keying from i18next's namespacing to next-intl's namespacing is mostly mechanical.
  • Ongoing cost: free (it's a library).
  • Downside: Next.js only, still key-based.

If you're on Next.js but the real pain is key management, see how to add i18n to a Next.js app for the i18n-keyless approach.

Step 3: Estimate migration cost​

Roughly:

App sizeLibrary-to-library migrationLibrary-to-keyless migrationAdd a TMS (no library change)
~100 strings1 sprint1 week2–3 days
~500 strings2 sprints2–3 weeks1 sprint
~2,000 strings1 month+1–2 months1 sprint
~10,000+ stringsQuarter-scale projectQuarter-scaleSprint-scale

Library-to-library migrations (i18next → react-intl, i18next → Lingui) are mostly mechanical: replace t("key") with <FormattedMessage id="key" defaultMessage="..." /> (or <Trans>...</Trans>), re-shape locale files, swap initialization. Tedious but predictable.

Library-to-keyless migrations are slightly more involved because you're inlining strings (replacing t("key") with the actual source string in the JSX). Compensates with no ongoing key maintenance after the migration.

Adding a TMS without changing the library is the cheapest option — you keep i18next, add Lokalise's CLI to push/pull locale files, integrate with CI. No code changes.

Step 4: Pick a dual-run strategy​

Every viable migration runs both libraries in parallel during the cutover. Some specifics:

  • i18next → i18n-keyless: install both, keyless handles new strings, sweep old strings file-by-file. See the migration guide.
  • i18next → react-intl: install both, set up <IntlProvider> alongside <I18nextProvider>, gradually replace t() calls with <FormattedMessage>. Same dual-run pattern.
  • i18next → Lingui: Lingui's @lingui/babel-plugin-extract-messages extracts your existing i18next strings if you migrate component-by-component. Dual-run during the sweep.
  • i18next → Tolgee: Tolgee has an i18next compatibility mode and an importer that takes your existing i18next locale files. Lower migration friction than full library swaps.
  • i18next → next-intl: the most painful migration if you're not on Next.js. Don't migrate to next-intl unless you're already on Next.js for unrelated reasons.

Step 5: Consider what you're not changing​

A trap: blaming i18next for problems that aren't i18next's fault.

  • Slow translator turnaround? That's a workflow / TMS problem, not a library problem. Adding Lokalise or Crowdin solves it without changing the library.
  • Bad copy? That's an editorial problem. No library will fix that.
  • Inconsistent terminology across the app? Glossaries (TMS feature) help. Switching libraries doesn't.
  • Bundle size concerns? Profile first — i18next's runtime is rarely the biggest contributor to JS bundle bloat. Tree-shaking your i18next config (loading only the namespaces you need per route) is often enough.

If the pain is really workflow-shaped (translators, glossaries, review), add a TMS to your existing i18next setup rather than swapping libraries. Cheaper migration, addresses the actual problem.

Step 6: Calculate total cost of switch​

For each option, multiply:

  • Migration cost (engineer time × team size × duration)
  • Ongoing cost (subscription + per-translation costs + maintenance)
  • Risk cost (vendor lock-in, library maturity, ecosystem support)

Example calculations for a 500-string SaaS app considering migration:

Option A: i18next + add Lokalise TMS

  • Migration: ~1 sprint × 1 engineer ≈ $5–10k engineering time
  • Ongoing: Lokalise subscription ~$50–500/mo + translator hours
  • Risk: low — both tools are mature

Option B: i18next → i18n-keyless

  • Migration: ~2 sprints × 1 engineer ≈ $10–20k engineering time
  • Ongoing: token-based pricing, typically $50–500/mo for early-stage usage
  • Risk: medium — newer tool, smaller community

Option C: i18next → react-intl

  • Migration: ~2 sprints × 1 engineer ≈ $10–20k
  • Ongoing: free (library), unless you add a TMS on top
  • Risk: low — both mature

Option D: stay on i18next, optimize the workflow

  • Migration: $0
  • Ongoing: same as today
  • Risk: zero

The "stay" option is often the right answer if the pain is moderate. The migration is real engineering investment.

When to NOT migrate​

Some honest signals you should stay on i18next:

  • ❌ Your team has under 3 active engineers — you don't have the bandwidth.
  • ❌ You're shipping a major release in the next quarter — don't add migration churn during high-stakes ship windows.
  • ❌ The pain you're trying to solve is workflow (translators) and adding a TMS without library change would solve it.
  • ❌ You'd be migrating "because keyless is cool" rather than "because key management is genuinely painful."
  • ❌ Your existing translation files represent significant investment (paid human translation across many locales) and the migration risk to that investment is real.

Solo founder, indie SaaS: → Migrate to i18n-keyless. Highest leverage on time saved.

Pre-Series A startup, no translators: → Migrate to i18n-keyless if key management is the pain. Stay on i18next + optimize if it isn't.

Series A+ with growing localization needs: → First, add a TMS (Lokalise or Crowdin). Don't change the library. If TMS doesn't solve the pain, then re-evaluate.

Mature SaaS with TMS already: → Don't migrate the library. Optimize the TMS workflow.

Open-source project: → Move to Crowdin (free for OSS) for community translation. Keep i18next as the runtime.

Next steps​