Migrate from TipTap to Eddyter 2026 (Complete Step-by-Step Guide With Code)

Migrate from TipTap to Eddyter 2026 (Complete Step-by-Step Guide With Code)

Deciding to migrate from TipTap to Eddyter in 2026 is one thing. Actually shipping the migration is another. This is not another Eddyter vs TipTap comparison. If you're still evaluating whether to switch, read Eddyter vs TipTap 2026 first. This guide assumes you've already decided to migrate and need the step-by-step to ship it.

This guide walks you through how to migrate from TipTap to Eddyter in 2026 with working code, extension mapping matrix, database migration script, rollback plan, and a 7-step deployment strategy. You'll see the full HTML pipeline. You'll get the exact database SQL. You'll know how to test in staging and ship to production without breaking user content.

The good news: to migrate from TipTap to Eddyter is easier than most editor migrations. Both editors output HTML. TipTap outputs it via editor.getHTML(). Eddyter accepts it via the initialContent prop. The migration is a pipeline, not a schema conversion. Total engineering time: 1-3 days for 10,000 documents. For 100,000 documents: 3-5 days including validation.

The short answer: Export TipTap HTML for every document. Save it alongside your existing storage. Install Eddyter in parallel. Point new sessions at Eddyter with the exported HTML as initialContent. Test in staging for 3-5 days. Ship. Deprecate TipTap after 30 days. This blog gives you the working code for every step.

🎥 New to Eddyter? Watch: What is Eddyter? Why Developers Are Switching in 2026

Why This Migration Guide Exists

Most editor migrations fail for the same reasons. Teams underestimate content complexity. They skip staging tests. They deploy without a rollback plan. Then user content breaks in production and the team scrambles to revert.

This guide exists to stop that from happening. Every step is tested against real migrations. Every code sample is production-ready. Every pitfall listed below has burned real teams.

If you're new to editor migrations in general, read Rich Text Editor Migration Checklist 2026 for the generic methodology. This TipTap-to-Eddyter guide assumes you know that framework and focuses on the specific pipeline.

Why Teams Migrate From TipTap to Eddyter

Before we dive into the code, here's the honest reason teams migrate:

1. Pricing Predictability

TipTap Cloud uses document-based pricing plus a $500/mo AI Toolkit add-on. Total stack for a mid-size SaaS: $7,788-$31,788/year. Eddyter AI Pro Managed is $708/year flat with multi-model AI included. Over 3 years, teams save $30K-$60K.

2. Multi-Model AI Included

TipTap AI Toolkit is single-provider (typically OpenAI). Eddyter includes GPT-5, Claude Sonnet 5, Haiku 4.5, and Gemini 3 with per-command model overrides.

3. Setup Time

TipTap headless requires 2-4 weeks of custom UI engineering. Eddyter ships production-ready in 10 minutes. This matters when you're building a new product on top of a migrated editor.

4. Framework Coverage

TipTap supports React, Vue 3, Svelte, and Vanilla JS (4 frameworks). Eddyter supports React, Next.js, Vue 3, Angular 17-20, Svelte 4/5, Laravel, and Vanilla JS (7 frameworks). Multi-framework teams stop maintaining separate editor codebases.

5. Managed Infrastructure

TipTap requires self-hosting or Cloud subscription for advanced features. Eddyter is fully managed on Premium plans — no infrastructure to run.

For deeper comparison, see Eddyter vs TipTap 2026, Best TipTap Alternative 2026, and TipTap Pricing Explained 2026.

Migration Overview at a Glance

Here's the complete migration flow at a high level:

Total active engineering time: 1-3 days for 10,000 documents. Total elapsed time including staging: 5-10 days.

Migration Timeline by Content Volume

Real migration times based on production migrations:

Larger migrations need more staging time. Not more code time. The migration script itself scales linearly.

Pre-Migration Checklist

Complete this checklist before writing any migration code.

1. Backup Every TipTap Document

Full database backup. Not just the editor content column. The whole database. If migration goes wrong, you restore from backup.

sql

1
2
3
4
-- PostgreSQL example
pg_dump -h your-host -U your-user -F c -b -v -f "backup-pre-migration-$(date +%Y%m%d).dump" your_database
-- MySQL example
mysqldump -u your-user -p --routines --triggers your_database > backup-pre-migration-$(date +%Y%m%d).sql

2. Audit Your TipTap Content

Run this SQL to understand your content volume:

sql

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
-- Count total documents
SELECT COUNT(*) as total_documents FROM your_content_table;
-- Content size distribution
SELECT
  CASE
    WHEN LENGTH(content) < 1000 THEN 'Under 1KB'
    WHEN LENGTH(content) < 10000 THEN '1KB - 10KB'
    WHEN LENGTH(content) < 100000 THEN '10KB - 100KB'
    ELSE 'Over 100KB'
  END as size_bucket,
  COUNT(*) as document_count
FROM your_content_table
GROUP BY size_bucket;
-- Find documents with custom TipTap extensions
SELECT COUNT(*) as documents_with_mentions
FROM your_content_table
WHERE content LIKE '%data-type="mention"%';
SELECT COUNT(*) as documents_with_tables
FROM your_content_table
WHERE content LIKE '%<table>%';
SELECT COUNT(*) as documents_with_code_blocks
FROM your_content_table
WHERE content LIKE '%<pre><code%';

3. Inventory Your TipTap Extensions

List every TipTap extension you use. Check your package.json:

bash

1
grep "@tiptap" package.json

Common extensions to look for:

• @tiptap/starter-kit
• @tiptap/extension-image
• @tiptap/extension-table
• @tiptap/extension-mention
• @tiptap/extension-collaboration
• @tiptap/extension-link
• @tiptap/extension-highlight
• @tiptap/extension-code-block-lowlight
• @tiptap-pro/extension-comment

Document each one. You'll need this for extension mapping (Step 3).

4. Plan Your Rollback Strategy

Before you write migration code, decide how you'll roll back if things break:

• Option A: Feature flag — Deploy both editors behind a feature flag. Flip users back to TipTap if issues appear.
• Option B: Route-based — New content on Eddyter, existing content on TipTap for 30 days.
• Option C: Full rollback — Restore database from backup and revert deployment.

Option A is safest. Option B works for gradual rollouts. Option C is nuclear — only when everything else fails.

5. Set Up Monitoring

Add error tracking for the editor before migration:

typescript

1
2
3
4
5
6
7
8
9
// Add to your error tracking (Sentry, Datadog, etc.)
import * as Sentry from '@sentry/nextjs';
Sentry.captureException(error, {
  tags: {
    component: 'editor',
    editor: 'eddyter',
    migration: 'tiptap-to-eddyter',
  },
});

Monitor for the first 7 days after production ship.

Step 1: Get Your Eddyter API Key

Visit eddyter.com/user/license-key. Copy your key. Add it to your environment file:

bash

1
2
3
4
5
# .env.local (Next.js)
NEXT_PUBLIC_EDDYTER_API_KEY=your-eddyter-api-key
# .env (Vite, Create React App)
REACT_APP_EDDYTER_API_KEY=your-eddyter-api-key
VITE_EDDYTER_API_KEY=your-eddyter-api-key

Step 2: Install Eddyter Alongside TipTap

Do NOT remove TipTap yet. Install Eddyter in parallel:

bash

1
2
3
# Keep TipTap installed
# Install Eddyter alongside
npm install eddyter

Verify both are in your package.json:

json

1
2
3
4
5
6
7
{
  "dependencies": {
    "@tiptap/react": "^2.10.0",
    "@tiptap/starter-kit": "^2.10.0",
    "eddyter": "^1.0.0"
  }
}

This parallel setup is what lets you A/B test in staging and roll back if needed.

Step 3: Map TipTap Extensions to Eddyter Features

Here's the complete mapping matrix for the most common TipTap extensions:

Handling Custom TipTap Nodes

If you built custom TipTap nodes, extract the underlying HTML they produce:

typescript

1
2
3
4
5
6
7
8
9
10
// Before migration — get sample HTML output from your custom node
const editor = new Editor({
  extensions: [
    StarterKit,
    YourCustomNode, // e.g., <div data-type="callout" data-color="blue">
  ],
});
const sampleHtml = editor.getHTML();
console.log(sampleHtml);
// Save this pattern — you'll recreate it in Eddyter with initialContent

Custom node HTML flows through Eddyter's initialContent as ordinary HTML. Custom rendering happens via Eddyter's custom nodes API (see Eddyter documentation).

Step 4: Export TipTap HTML for Every Document

This is the core of the migration. Extract HTML from every TipTap document and save it to a new database column.

4.1: Add a New Column for Eddyter HTML

sql

1
2
3
4
5
6
7
-- PostgreSQL / MySQL
ALTER TABLE your_content_table
ADD COLUMN eddyter_content TEXT;
-- Add an index for the migration status
ALTER TABLE your_content_table
ADD COLUMN migration_status VARCHAR(20) DEFAULT 'pending';
CREATE INDEX idx_migration_status ON your_content_table(migration_status);

4.2: Write the Migration Script

For content already stored as TipTap-generated HTML, you're mostly copying data over. Here's the Node.js migration script:

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
// scripts/migrate-tiptap-to-eddyter.ts
import { PrismaClient } from '@prisma/client';
import { JSDOM } from 'jsdom';
const prisma = new PrismaClient();
const BATCH_SIZE = 100;
const CHECKPOINT_INTERVAL = 1000;
interface MigrationResult {
  successful: number;
  failed: number;
  errors: Array<{ id: string; error: string }>;
}
async function migrateTiptapToEddyter(): Promise<MigrationResult> {
  const result: MigrationResult = {
    successful: 0,
    failed: 0,
    errors: [],
  };
  let processed = 0;
  let hasMore = true;
  console.log('Starting TipTap → Eddyter migration...');
  const startTime = Date.now();
  while (hasMore) {
    const documents = await prisma.document.findMany({
      where: { migration_status: 'pending' },
      take: BATCH_SIZE,
      orderBy: { id: 'asc' },
    });
    if (documents.length === 0) {
      hasMore = false;
      break;
    }
    for (const doc of documents) {
      try {
        // TipTap HTML is already valid HTML — Eddyter accepts it directly
        // Only sanitization needed
        const cleanHtml = sanitizeTiptapHtml(doc.content);
        // Validate the HTML parses correctly
        const validated = validateHtml(cleanHtml);
        // Update the document
        await prisma.document.update({
          where: { id: doc.id },
          data: {
            eddyter_content: validated,
            migration_status: 'migrated',
          },
        });
        result.successful++;
      } catch (error) {
        result.failed++;
        result.errors.push({
          id: doc.id,
          error: error instanceof Error ? error.message : String(error),
        });
        await prisma.document.update({
          where: { id: doc.id },
          data: { migration_status: 'failed' },
        });
      }
      processed++;
      // Checkpoint logging
      if (processed % CHECKPOINT_INTERVAL === 0) {
        const elapsed = (Date.now() - startTime) / 1000;
        const rate = processed / elapsed;
        console.log(
          `Processed: ${processed} | Success: ${result.successful} | Failed: ${result.failed} | Rate: ${rate.toFixed(2)} docs/sec`
        );
      }
    }
  }
  const totalTime = (Date.now() - startTime) / 1000;
  console.log(`\nMigration complete in ${totalTime.toFixed(2)}s`);
  console.log(`Successful: ${result.successful} | Failed: ${result.failed}`);
  if (result.errors.length > 0) {
    console.log('\nFailed documents (first 10):');
    result.errors.slice(0, 10).forEach((err) => {
      console.log(`  ${err.id}: ${err.error}`);
    });
  }
  return result;
}
function sanitizeTiptapHtml(html: string): string {
  // TipTap outputs are generally clean, but strip any residual issues:
  // - Empty paragraphs from paste
  // - TipTap-specific data attributes that Eddyter doesn't need
  // - Any script or style tags that shouldn't be there
  let cleaned = html;
  // Remove empty paragraphs
  cleaned = cleaned.replace(/<p><\/p>/g, '');
  // Remove any script tags (XSS defense)
  cleaned = cleaned.replace(/<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gi, '');
  // Remove style tags (XSS defense)
  cleaned = cleaned.replace(/<style\b[^<]*(?:(?!<\/style>)<[^<]*)*<\/style>/gi, '');
  // Remove TipTap-specific attributes that Eddyter doesn't use
  cleaned = cleaned.replace(/data-node-view-content=""/g, '');
  cleaned = cleaned.replace(/data-node-view-wrapper=""/g, '');
  return cleaned.trim();
}
function validateHtml(html: string): string {
  // Use JSDOM to verify HTML parses correctly
  try {
    const dom = new JSDOM(`<!DOCTYPE html><html><body>${html}</body></html>`);
    const body = dom.window.document.body;
    return body.innerHTML;
  } catch (error) {
    throw new Error(`Invalid HTML: ${error instanceof Error ? error.message : String(error)}`);
  }
}
// Run the migration
migrateTiptapToEddyter()
  .catch(console.error)
  .finally(() => prisma.$disconnect());

4.3: Run the Migration in Batches

Run the migration during off-peak hours. For most SaaS products, that's 2-4 AM in your primary user timezone:

bash

1
2
3
4
# Test on staging first
NODE_ENV=staging tsx scripts/migrate-tiptap-to-eddyter.ts
# Then production
NODE_ENV=production tsx scripts/migrate-tiptap-to-eddyter.ts

Monitor the checkpoint output. Typical rates: 50-200 documents/second depending on document size and database performance.

4.4: Handle Custom TipTap Extensions

If you use custom TipTap extensions that produce non-standard HTML, add a transformer:

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Handle @tiptap/extension-mention output
function transformMentionsForEddyter(html: string): string {
  // TipTap mention output:
  // <span data-type="mention" data-id="123">@johndoe</span>
  // Eddyter mention output:
  // <span class="eddyter-mention" data-user-id="123">@johndoe</span>
  return html.replace(
    /<span data-type="mention" data-id="([^"]+)">([^<]+)<\/span>/g,
    '<span class="eddyter-mention" data-user-id="$1">$2</span>'
  );
}
// Handle @tiptap/extension-highlight with custom colors
function transformHighlightsForEddyter(html: string): string {
  // TipTap highlight output:
  // <mark data-color="yellow">text</mark>
  // Eddyter highlight output (uses inline style):
  // <mark style="background-color: yellow">text</mark>
  return html.replace(
    /<mark data-color="([^"]+)">([^<]+)<\/mark>/g,
    '<mark style="background-color: $1">$2</mark>'
  );
}

Add these transformers to sanitizeTiptapHtml() in the migration script.

Step 5: Update Your Editor Component

Replace your TipTap editor component with Eddyter. Keep the old TipTap component in a separate file for rollback:

5.1: Before — TipTap Component

tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// components/TipTapEditor.tsx (existing — keep for rollback)
"use client";
import { useEditor, EditorContent } from '@tiptap/react';
import StarterKit from '@tiptap/starter-kit';
export default function TipTapEditor({ content, onChange }: {
  content: string;
  onChange: (html: string) => void;
}) {
  const editor = useEditor({
    extensions: [StarterKit],
    content,
    onUpdate: ({ editor }) => {
      onChange(editor.getHTML());
    },
  });
  return <EditorContent editor={editor} />;
}

5.2: After — Eddyter Component

tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// components/EddyterEditor.tsx (new)
"use client";
import {
  ConfigurableEditorWithAuth,
  EditorProvider,
} from 'eddyter';
import 'eddyter/style.css';
export default function EddyterEditor({ content, onChange }: {
  content: string;
  onChange: (html: string) => void;
}) {
  const apiKey = process.env.NEXT_PUBLIC_EDDYTER_API_KEY;
  return (
    <EditorProvider>
      <ConfigurableEditorWithAuth
        apiKey={apiKey}
        initialContent={content}
        onChange={onChange}
      />
    </EditorProvider>
  );
}

5.3: Feature Flag Wrapper (Recommended)

Wrap both editors with a feature flag for safe rollout:

tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// components/Editor.tsx
"use client";
import { useFeatureFlag } from '@/lib/feature-flags';
import TipTapEditor from './TipTapEditor';
import EddyterEditor from './EddyterEditor';
interface EditorProps {
  content: string;
  eddyterContent?: string;
  onChange: (html: string) => void;
}
export default function Editor({ content, eddyterContent, onChange }: EditorProps) {
  const useEddyter = useFeatureFlag('use-eddyter-editor');
  if (useEddyter) {
    return (
      <EddyterEditor
        content={eddyterContent ?? content}
        onChange={onChange}
      />
    );
  }
  return <TipTapEditor content={content} onChange={onChange} />;
}

Now you can flip users to Eddyter gradually via the feature flag.

Step 6: Update Your API to Save Eddyter HTML

Update your save endpoint to write to the new eddyter_content column:

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// app/api/documents/[id]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient();
export async function PATCH(
  request: NextRequest,
  { params }: { params: { id: string } }
) {
  const body = await request.json();
  const { content } = body;
  // Save to new column
  const updated = await prisma.document.update({
    where: { id: params.id },
    data: {
      eddyter_content: content,
      // Keep writing to old column for 30-day rollback window
      content: content,
      migration_status: 'migrated',
      updated_at: new Date(),
    },
  });
  return NextResponse.json(updated);
}

Dual-write to both columns for 30 days. This means you can roll back to TipTap at any point without losing new content.

Step 7: Test in Staging (3-5 Days)

Never skip staging validation. Here's the required test matrix:

7.1: Content Validation Tests

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// tests/migration-validation.test.ts
import { render } from '@testing-library/react';
import EddyterEditor from '@/components/EddyterEditor';
describe('TipTap to Eddyter migration', () => {
  test('renders migrated TipTap content correctly', () => {
    const tiptapHtml = '<p>Test <strong>bold</strong> and <em>italic</em></p>';
    const { container } = render(
      <EddyterEditor content={tiptapHtml} onChange={() => {}} />
    );
    expect(container.querySelector('strong')?.textContent).toBe('bold');
    expect(container.querySelector('em')?.textContent).toBe('italic');
  });
  test('renders migrated tables correctly', () => {
    const tiptapTableHtml = `
      <table>
        <tbody>
          <tr><td>A1</td><td>B1</td></tr>
          <tr><td>A2</td><td>B2</td></tr>
        </tbody>
      </table>
    `;
    const { container } = render(
      <EddyterEditor content={tiptapTableHtml} onChange={() => {}} />
    );
    const cells = container.querySelectorAll('td');
    expect(cells).toHaveLength(4);
  });
  test('renders migrated code blocks correctly', () => {
    const tiptapCodeHtml = '<pre><code class="language-typescript">const x = 1;</code></pre>';
    const { container } = render(
      <EddyterEditor content={tiptapCodeHtml} onChange={() => {}} />
    );
    expect(container.querySelector('pre code')?.textContent).toBe('const x = 1;');
  });
  test('handles empty content gracefully', () => {
    const { container } = render(
      <EddyterEditor content="" onChange={() => {}} />
    );
    expect(container).toBeTruthy();
  });
  test('preserves images with src and alt', () => {
    const tiptapImageHtml = '<img src="/test.png" alt="Test image" />';
    const { container } = render(
      <EddyterEditor content={tiptapImageHtml} onChange={() => {}} />
    );
    const img = container.querySelector('img');
    expect(img?.getAttribute('src')).toBe('/test.png');
    expect(img?.getAttribute('alt')).toBe('Test image');
  });
});

Run this test suite against a sample of 1000 real production documents. Flag any failures.

7.2: Visual Regression Tests

For every content type, render both editors side-by-side and compare:

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// tests/visual-regression.test.ts
import { chromium } from 'playwright';
async function visualRegressionTest() {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  // Load your staging URL with a specific document
  await page.goto('https://staging.your-app.com/documents/sample-doc?editor=tiptap');
  const tiptapScreenshot = await page.screenshot({ fullPage: true });
  await page.goto('https://staging.your-app.com/documents/sample-doc?editor=eddyter');
  const eddyterScreenshot = await page.screenshot({ fullPage: true });
  // Compare screenshots (use pixelmatch or similar)
  const diff = await compareScreenshots(tiptapScreenshot, eddyterScreenshot);
  console.log(`Visual diff: ${diff}% pixels different`);
  await browser.close();
}

Acceptable diff: under 2% (accounts for cursor position, focus rings, font rendering).

7.3: Edge Case Test Cases

Test every edge case that has burned teams in past migrations:

• ✅ Empty documents
• ✅ Very large documents (over 100 KB)
• ✅ Documents with 100+ nested lists
• ✅ Documents with 50+ tables
• ✅ Documents with special characters (emojis, RTL text, CJK characters)
• ✅ Documents with 500+ inline links
• ✅ Documents with malformed HTML (test error handling)
• ✅ Documents with custom extensions from Step 3

Step 8: Ship to Production

After 3-5 days of successful staging tests, ship to production.

8.1: Gradual Rollout via Feature Flag

Start with 5% of users:

typescript

1
2
3
4
5
6
7
8
9
10
// lib/feature-flags.ts
export function useFeatureFlag(flag: string): boolean {
  // Your feature flag provider (LaunchDarkly, Statsig, Unleash, etc.)
  const rollout = {
    'use-eddyter-editor': 0.05, // 5% initially
  };
  const userId = getCurrentUserId();
  const hash = hashUserId(userId);
  return hash < rollout[flag];
}

Increase gradually: 5% → 25% → 50% → 100% over 7 days.

Monitor error rates at each step. If errors spike, roll back to the previous percentage.

8.2: Monitor for the First 7 Days

Track these metrics:

• Editor error rate (target: under 0.1%)
• Save error rate (target: under 0.01%)
• Page load time (target: within 100ms of TipTap baseline)
• User support tickets mentioning "editor" (target: no increase)
• Bundle size impact (Eddyter ~140 KB vs TipTap ~165 KB — should be similar or smaller)

8.3: Communicate the Migration to Users

Send an in-app notification when users hit the new editor:

tsx

1
2
3
4
5
6
7
8
9
10
// components/EddyterEditor.tsx
useEffect(() => {
  const hasSeenMigrationNotice = localStorage.getItem('eddyter-migration-notice-seen');
  if (!hasSeenMigrationNotice) {
    toast.info('We\'ve upgraded our editor. Faster loading, AI features, cleaner formatting. Let us know if you spot anything.', {
      duration: 8000,
    });
    localStorage.setItem('eddyter-migration-notice-seen', 'true');
  }
}, []);

Step 9: Deprecate TipTap (30 Days After 100% Rollout)

After 30 days of stable 100% rollout, remove TipTap:

9.1: Remove TipTap Dependencies

bash

1
npm uninstall @tiptap/react @tiptap/starter-kit @tiptap/pm @tiptap/extension-image @tiptap/extension-table @tiptap/extension-mention @tiptap-pro/extension-comment

9.2: Delete TipTap Components

bash

1
2
3
rm components/TipTapEditor.tsx
rm -rf lib/tiptap-utils
rm -rf hooks/use-tiptap-*.ts

9.3: Simplify Feature Flag Wrapper

tsx

1
2
3
4
5
6
7
8
9
// components/Editor.tsx (simplified)
"use client";
import EddyterEditor from './EddyterEditor';
export default function Editor({ content, onChange }: {
  content: string;
  onChange: (html: string) => void;
}) {
  return <EddyterEditor content={content} onChange={onChange} />;
}

9.4: Drop the Old Column

sql

1
2
3
4
5
6
7
8
9
10
-- After 60 days of stable 100% Eddyter usage
-- (Wait longer if you're risk-averse)
ALTER TABLE your_content_table
DROP COLUMN content;
-- Rename eddyter_content to content
ALTER TABLE your_content_table
RENAME COLUMN eddyter_content TO content;
-- Drop migration status column
ALTER TABLE your_content_table
DROP COLUMN migration_status;

9.5: Cancel Your TipTap Subscription

Log into TipTap Cloud. Cancel your subscription. Save the annual savings.

For most mid-size SaaS teams, this is when the $30K-$60K over 3 years starts.

7 Common Pitfalls in TipTap → Eddyter Migrations

Teams migrating from TipTap to Eddyter consistently hit these issues. Each has a specific fix.

Pitfall 1: Skipping the Staging Phase

Teams migrate directly in production because "the HTML output is compatible." Then a specific document type breaks and 5% of users lose the ability to edit their content.

Fix: Always run at least 3 days of staging tests with real production data samples. No exceptions.

Pitfall 2: Not Handling Custom TipTap Nodes

If you built custom TipTap nodes (callouts, custom embeds, drag-drop widgets), their HTML output won't render correctly in Eddyter without transformation.

Fix: Run the transformation functions in sanitizeTiptapHtml(). Test every custom node type before shipping.

Pitfall 3: Forgetting to Dual-Write During Rollout

If you write only to eddyter_content immediately, you can't roll back without losing user edits from the rollout window.

Fix: Dual-write to both columns for 30 days after 100% rollout. Drop the old column only after 60 days.

Pitfall 4: Missing Extension Feature Parity Check

Some teams migrate assuming feature parity. Then they discover Eddyter's Q3/Q4 2026 features (RTC, comments, track changes) aren't available yet for their production launch.

Fix: Check the extension mapping matrix (Step 3) against your feature usage. For features not yet native in Eddyter, plan the timing: use CKEditor 5 for track changes today, migrate to Eddyter native Q4 2026.

Pitfall 5: Underestimating Content Volume Complexity

10,000 documents at 1 KB each is trivial. 10,000 documents at 500 KB each is a multi-day migration script tuning exercise.

Fix: Run the audit SQL in Step 2 first. Adjust batch size (BATCH_SIZE = 100) based on average document size. For large documents, use BATCH_SIZE = 10-25.

Pitfall 6: Not Setting Up Rollback Infrastructure

Teams ship without rollback capability. When issues appear, they panic-revert and lose new content.

Fix: Feature flag + dual-write + database backup. All three. Every migration.

Pitfall 7: Ignoring Mobile Testing

TipTap's mobile UX and Eddyter's mobile UX have subtle differences. Teams test on desktop and ship, only to have mobile users report broken selection.

Fix: Test on real iOS Safari and Android Chrome during staging. Both have different touch selection behavior.

Rollback Plan (If Things Go Wrong)

If migration causes production issues, roll back in this order:

Level 1: Feature Flag Rollback (Fastest, 30 Seconds)

Flip the feature flag to 0% Eddyter. All users immediately revert to TipTap. Their content is still there because you dual-wrote.

typescript

1
2
// Update your feature flag provider
featureFlags.set('use-eddyter-editor', 0);

Level 2: Code Rollback (5 Minutes)

If the feature flag alone doesn't help (a code issue), redeploy the previous version:

bash

1
2
3
4
5
# Revert to the commit before Eddyter deployment
git revert <migration-commit-hash>
git push origin main
# Or use your CI/CD tool to redeploy the previous version
vercel rollback  # If on Vercel

Level 3: Database Rollback (30 Minutes to 4 Hours)

Only if data corruption occurred. Restore from the backup taken in Step 1 of pre-migration checklist:

bash

1
2
3
4
# PostgreSQL
pg_restore -h your-host -U your-user -d your_database -c backup-pre-migration-20260923.dump
# MySQL
mysql -u your-user -p your_database < backup-pre-migration-20260923.sql

Then redeploy the previous code version. This is the "nuclear option" — use only when Levels 1 and 2 fail.

Real Migration Costs (What This Migration Actually Saves)

For a typical SaaS with 500 active editors and 50,000 documents:

Before Migration (TipTap)

• TipTap Cloud Team: $149/mo × 12 = $1,788/year
• TipTap AI Toolkit: $500/mo × 12 = $6,000/year
• Custom UI engineering (already invested): $18,000 one-time
• Ongoing maintenance: 5 hrs/mo × $150 × 12 = $9,000/year
• Total annual TipTap cost: $16,788/year

After Migration (Eddyter)

• Eddyter AI Pro Managed: $59/mo × 12 = $708/year
• Migration engineering (one-time): 1-3 days = $1,800-$5,400
• Ongoing maintenance: 1 hr/mo × $150 × 12 = $1,800/year
• Total annual Eddyter cost: $2,508/year

3-Year Savings

• Year 1: ($16,788 - $2,508) - $5,400 migration cost = $8,880 net savings
• Year 2: $16,788 - $2,508 = $14,280 savings
• Year 3: $16,788 - $2,508 = $14,280 savings
• Total 3-year savings: $37,440

That's before counting the value of multi-model AI, faster feature velocity, and 7-framework support.

For build-vs-buy analysis, see Build vs Buy: Real Cost of Building a Rich Text Editor 2026.

Frequently Asked Questions

1. How long does it take to migrate from TipTap to Eddyter?

For most teams, the migration takes 1-3 days of active engineering time for up to 10,000 documents. Total elapsed time including staging validation: 5-10 days. For 100,000 documents, expect 3-5 days engineering + 5-10 days staging = 10-15 days total. For 1M+ documents, plan 5-10 days engineering + 2-3 weeks staging = 4-6 weeks total. The migration script itself scales linearly — larger content volumes just need more staging time to catch edge cases. Both editors output HTML, so there's no schema conversion. TipTap outputs HTML via editor.getHTML(). Eddyter accepts it via the initialContent prop. Migration is a pipeline, not a rewrite.

2. Do I lose any content when I migrate from TipTap to Eddyter?

No, if you follow the migration steps in this guide. Both editors use HTML as their storage format, so basic text, formatting (bold, italic, headings, lists, links), tables, images, and code blocks migrate cleanly with no data loss. The migration script (Step 4) copies HTML from TipTap to a new eddyter_content column while preserving the original. Dual-writing for 30 days after 100% rollout gives you a rollback window. Custom TipTap nodes require transformation (Step 4.4) but no data is destroyed — the underlying HTML is preserved. Backup your database before migration (Step 0.1) as an extra safety net. Real migrations report near-zero data loss when this guide is followed.

3. What TipTap features are NOT yet available in Eddyter?

Three TipTap features aren't yet native in Eddyter (as of Q3 2026): Real-time collaboration — Eddyter native RTC launches Q3 2026. Use CKEditor 5 today if you need RTC in production immediately, migrate to Eddyter native at launch. Comments and annotations — Eddyter native comments launch Q4 2026. Same pattern applies. Track changes — Eddyter native track changes launch Q4 2026. For teams needing these features immediately, keep TipTap or CKEditor 5 for those specific features while migrating everything else to Eddyter. Everything else in TipTap (tables, images, mentions, code blocks, custom nodes) has direct Eddyter equivalents shipping today. Check the extension mapping matrix (Step 3) for full compatibility details.

4. Can I roll back to TipTap after migrating to Eddyter?

Yes. This guide includes a 3-level rollback plan. Level 1 (fastest, 30 seconds): Flip your feature flag to 0% Eddyter. All users immediately revert to TipTap. Content is preserved because you dual-wrote to both columns for 30 days. Level 2 (5 minutes): Redeploy the previous version if the feature flag alone doesn't help. Level 3 (30 minutes to 4 hours): Restore from the database backup taken pre-migration if data corruption occurred. The feature flag + dual-write + backup pattern makes rollback safe at any point in the first 30 days after 100% rollout. After 30 days, the old TipTap column can be dropped safely. Never migrate without these three rollback layers in place.

5. How do I handle custom TipTap extensions during migration?

Custom TipTap extensions require case-by-case migration. First, identify every custom extension in your codebase (grep package.json for @tiptap and audit your custom code). For each one, extract the HTML output pattern it produces (Step 3). Then either: (a) Add a transformation function to sanitizeTiptapHtml() that converts the TipTap HTML to Eddyter-compatible HTML (see Step 4.4 for mention and highlight examples), or (b) Build a custom Eddyter node that renders the migrated HTML the way you want. For most custom nodes (callouts, custom embeds, drag-drop widgets), option (a) works because the underlying HTML is standard. Only if you need custom rendering behavior in Eddyter do you need option (b). Full custom node documentation is at eddyter.com/docs.

6. Is TipTap to Eddyter migration worth it for small products?

For small products (under 100 active users, under 1,000 documents), the migration ROI depends on your AI needs. If you're on TipTap free MIT core with no AI, no cloud features, and no active engineering pain, migration might not be worth 1-3 days of engineering time. If you're paying for TipTap Cloud ($49-$999/mo) + AI Toolkit ($500/mo) with just a few users, migration to Eddyter Starter ($12/mo) or Pro ($29/mo) pays back within 2-3 months. Even at $12/mo, Eddyter delivers 7-framework support, cleaner setup, and Q4 2026 native track changes/comments. For AI-native products, migration is worth it at any scale because multi-model AI at flat pricing beats single-provider paid add-ons. Do the math: current annual TipTap cost vs $708/year Eddyter AI Pro Managed.

Ready to Migrate From TipTap to Eddyter?

Stop paying for TipTap Cloud + AI Toolkit stack. Migrate to Eddyter — production-ready in 10 minutes with multi-model AI included at $12-$59/mo flat. Full migration takes 1-3 days for 10,000 documents.

Get started:

👉 Try Eddyter free at eddyter.com
📚 Read the docs
💰 See pricing
🎥 Watch the intro video | Watch the 30-min integration guide