Re:amaze FAQ to Freshservice Knowledge Base Migration Guide

Re:amaze FAQ to Freshservice Knowledge Base Migration Guide

Migrating FAQ content from Re:amaze to Freshservice means translating a two-level, brand-scoped article system into Freshservice's three-level Solutions hierarchy. There is no native import tool between these platforms. You need to extract via the Re:amaze API, transform the data model, and load through the Freshservice Solutions API — handling HTML content conversion, image re-hosting, status mapping, and structural differences along the way.

If you export a CSV from Re:amaze and try to push it into Freshservice, you will fail. Re:amaze relies on inline HTML, proprietary image hosting, and dynamic variables. Moving this data requires extracting raw HTML via the API, rewriting image URIs, mapping a two-tier hierarchy to a three-tier hierarchy, and pushing sanitized payloads through the Freshservice Solutions API.

This guide covers the full technical path: API extraction, hierarchy mapping, content transformation, image handling, rate limit management, and the edge cases that will quietly corrupt your knowledge base if you miss them.

Why Teams Move Re:amaze FAQ Content to Freshservice

Re:amaze is a customer messaging platform with a built-in FAQ feature designed for e-commerce support. Each brand in Re:amaze comes with an FAQ that can be deployed as a standalone Help Site on its own domain, embedded inline on your website, or integrated into the Re:amaze Shoutbox or Lightbox. It works well for consumer-facing self-service.

Freshservice is an IT service management (ITSM) platform. Its knowledge base — called Solutions — is built for internal IT documentation, employee self-service, and agent-facing reference material.

Teams make this move for structural reasons:

• IT consolidation. The company adopted Freshservice for ITSM and wants all knowledge in a single platform rather than maintaining Re:amaze separately.
• Access control and workspaces. Freshservice folders support visibility controls: visible to all users, only logged-in users, agents only, or specific departments. Re:amaze limits permissions primarily to internal vs. public articles.
• Service catalog integration. Freshservice solutions natively link to the Service Catalog and Incident Management workflows. An article about "VPN Troubleshooting" can directly embed a request item for "Request New VPN Credentials."
• Freddy AI integration. Freddy AI can draft help articles with a simple prompt, create articles from tickets, and pull information from a service desk and public sources. Centralizing your KB content in Freshservice lets Freddy use it for ticket deflection — a common driver for teams consolidating standalone AI bots into Freshservice.
• Three-level hierarchy. Freshservice Knowledge Base solutions are grouped under a three-tier hierarchy: Categories → Folders → Solutions. Re:amaze only provides Topics → Articles, which limits organization for large documentation sets.

Pause before migrating if your core requirement is a public, deeply embedded help center that behaves like part of your storefront or app. Re:amaze's inline FAQ, Shoutbox, and Lightbox experiences have no direct Freshservice equivalent. Freshservice focuses on structured portal knowledge, permissions, and departmental access. Verify those gaps before you shut down the old Help Site. If you need to maintain a robust external help center while leaving Re:amaze, a migration to Zendesk is often a better architectural fit.

Data Model: Re:amaze FAQ vs. Freshservice Solutions

The structural gap between these two systems is where most migration complexity lives.

Sub-folders and Plan Tiers

Sub-folders are only available on Freshservice Pro and Enterprise plans, and only when using the portal v2 interface. On Starter and Growth plans, the hierarchy is strictly three levels: Category → Folder → Article. If your Re:amaze Topics are granular enough that you need four levels of nesting, verify your Freshservice plan before designing the target hierarchy — you may need to consolidate Topics rather than nest them.

The Visibility Mismatch

This is the biggest semantic mismatch between the two platforms. Re:amaze visibility is article-centric: Published is public, Draft is work in progress, Internal is staff-only, and Unlisted is accessible by direct URL but hidden from navigation and search.

Freshservice splits this across two controls: the article itself can be draft or published, but visibility is managed on folders with options including All Users, Logged-in Users, Agents Only, Departments, Agent Groups, and Requester Groups. Freshservice draft articles remain visible on the agent portal.

That means a Re:amaze Internal article usually maps better to a published article inside an agents-only folder than to a draft article. Using Draft as your internal knowledge state gives agents access anyway while marking the content as unfinished — the wrong signal.

Concrete Freshservice Patterns for Re:amaze Unlisted Articles

"Redesign case by case" is not actionable. Here are three concrete Freshservice configurations that approximate unlisted behavior, with tradeoffs:

Pattern 1 — Logged-in folder with direct URL sharing. Set the Folder visibility to 2 (Logged-in Users). The article does not appear in self-service portal navigation or search for anonymous visitors, but any logged-in requester who has the direct article URL can access it. Tradeoff: requires authentication, so it does not work for articles shared with unauthenticated external users.

Pattern 2 — Agents-only folder with manual sharing. Set the Folder visibility to 3 (Agents Only). The article is invisible to all end-users in navigation and search. Agents can copy the direct URL and share it manually. Tradeoff: the recipient must be an agent or have agent-level portal access.

Pattern 3 — Department-scoped folder. Set the Folder visibility to 4 (Specific Departments) and assign the relevant department IDs. The article is invisible to everyone outside those departments. Tradeoff: requires requesters to be mapped to the correct Freshservice department; does not replicate truly anonymous direct-URL access.

None of these patterns perfectly replicate Re:amaze's unlisted behavior (anonymous access via direct URL, hidden from navigation). If anonymous unlisted access is required, the closest alternative is hosting the content in a separate system (Notion, Confluence public pages) and linking from Freshservice.

API Constraints and Rate Limits

Before writing your migration scripts, understand the limits of both platforms.

Re:amaze API

Re:amaze API access is available only through SSL/HTTPS. All authentication is performed via HTTP Basic Auth. Your HTTP header must either contain application/json as an Accept type or you must suffix the resource URL with .json.

Use the GET /api/v1/articles endpoint to pull all FAQ articles. Use GET /api/v1/topics to pull all Topics (required to build the hierarchy mapping table — article responses reference topic.slug but not the full topic metadata). The response is paginated with a default page size of 30 and includes page_size, page_count, and total_count.

The Re:amaze API is rate limited per API token per minute. The exact limit is not publicly documented in Re:amaze's API reference. In practice, observe the HTTP 429 Too Many Requests response and build exponential backoff from the start. A conservative starting point is treating the limit as 60 requests per minute and adjusting based on observed behavior.

Freshservice API

Freshservice authenticates via an API key passed as the username in Basic Auth (with X as the password). Rate limits vary by plan:

• Starter: 100 requests/minute
• Growth: 200 requests/minute
• Pro: 400 requests/minute
• Enterprise: 500 requests/minute

Sub-limits apply to specific operations within the overall rate envelope. All limits are account-wide regardless of the number of agents or IP addresses making calls.

Every Freshservice API response includes rate limit headers:

X-RateLimit-Total: 400
X-RateLimit-Remaining: 297
X-RateLimit-Used-CurrentRequest: 1

Rate limits apply to all API calls, even if they fail. Build your migration script to read the X-RateLimit-Remaining header and pause when it drops below a safety threshold (e.g., 10 remaining). Freshservice offers a migration partner program that increases the rate limit to 700 requests per minute for a defined migration window. If you are migrating 500+ articles, request this uplift through Freshservice support before beginning.

Common Freshservice 4xx Errors on Article Creation

Engineers lose significant time to validation errors that are not well-documented. The most common causes of 422 Unprocessable Entity on POST /api/v2/solutions/folders/{folder_id}/articles:

A 403 Forbidden on folder or category creation usually means the API key belongs to an agent without admin-level permissions. Knowledge base administration requires admin or IT Operations Manager role in Freshservice.

Step-by-Step Migration Process

Step 1: Extract All Topics and Articles from Re:amaze

Start with a full inventory — Topics first, then Articles. You need Topics extracted separately because the article API response includes topic.slug but not the full topic metadata (name, position, description) required to reconstruct the hierarchy.

Extract Topics:

curl 'https://{brand}.reamaze.io/api/v1/topics?page=1' \
  -u {login-email}:{api-token} \
  -H 'Accept: application/json'

Each topic object contains name, slug, position, and description. Store these as your source hierarchy.

Extract Articles:

curl 'https://{brand}.reamaze.io/api/v1/articles?page=1' \
  -u {login-email}:{api-token} \
  -H 'Accept: application/json'

Each article object contains title, body (full HTML), slug, status (integer: 0 = Published, 1 = Draft, 4 = Internal), created_at/updated_at timestamps, author (object with name and email), and topic (object with name and slug).

Extract all statuses:

import requests
import time
 
def extract_reamaze_topics(brand, email, token):
    base_url = f"https://{brand}.reamaze.io/api/v1/topics"
    topics = []
    page = 1
    while True:
        resp = requests.get(
            f"{base_url}?page={page}",
            auth=(email, token),
            headers={'Accept': 'application/json'}
        )
        if resp.status_code == 429:
            time.sleep(60)
            continue
        data = resp.json()
        topics.extend(data.get('topics', []))
        if page >= data.get('page_count', 1):
            break
        page += 1
    return topics
 
def extract_reamaze_articles(brand, email, token):
    base_url = f"https://{brand}.reamaze.io/api/v1/articles"
    articles = []
    
    for status in ['published', 'draft', 'internal']:
        page = 1
        while True:
            resp = requests.get(
                f"{base_url}?status={status}&page={page}",
                auth=(email, token),
                headers={'Accept': 'application/json'}
            )
            if resp.status_code == 429:
                time.sleep(60)
                continue
            data = resp.json()
            articles.extend(data.get('articles', []))
            if page >= data.get('page_count', 1):
                break
            page += 1
    
    return articles

Store these JSON responses locally. Do not pipe data directly from Re:amaze to Freshservice in real-time. A local staging database (SQLite for smaller KBs, PostgreSQL for larger ones) lets you process HTML and images without holding open API connections.

Step 2: Map the Hierarchy — Topics to Categories and Folders

This is the step most teams get wrong. Re:amaze has a flat two-level structure (Topics contain Articles). Freshservice enforces three levels (Categories contain Folders, Folders contain Articles). You cannot skip the Folder level.

Two practical strategies:

Strategy A: One Topic → One Category with a Default Folder. Create one Freshservice Category per Re:amaze Topic. Inside each, create a single Folder (e.g., "General" or matching the Topic name). This works well when your Re:amaze Topics represent distinct subject areas with fewer than ~50 articles each.

Strategy B: Consolidate Topics into Fewer Categories. If you have many small Re:amaze Topics (10+ topics with 5–10 articles each), consolidate them into broader Freshservice Categories with one Folder per former Topic. For example, "Shipping FAQ" and "Returns FAQ" become Folders under a single "Orders & Fulfillment" Category.

If a Re:amaze Topic contains both Published and Internal articles, you must split them into separate Freshservice Folders. Freshservice manages visibility at the Folder level — you cannot mix public and agents-only articles in the same Folder. Name them explicitly: "Billing - Public" (visibility = 1) and "Billing - Internal" (visibility = 3).

If your Re:amaze account has multiple brands, decide upfront whether each brand becomes a Freshservice workspace, a top-level category, or some other division. Do not decide this mid-migration — it changes permissions, navigation, and long-term ownership.

Create the structure via API:

# Create a Category
curl -X POST 'https://{domain}.freshservice.com/api/v2/solutions/categories' \
  -u {api-key}:X \
  -H 'Content-Type: application/json' \
  -d '{"name": "Shipping & Returns", "description": "Migrated from Re:amaze"}'
 
# Create a Folder inside the Category
curl -X POST 'https://{domain}.freshservice.com/api/v2/solutions/categories/{category_id}/folders' \
  -u {api-key}:X \
  -H 'Content-Type: application/json' \
  -d '{"name": "Returns FAQ", "description": "Migrated from Re:amaze", "visibility": 1}'

Folder visibility values:

• 1 — All users (visible on self-service portal)
• 2 — Logged-in users only
• 3 — Agents only
• 4 — Specific departments (requires department_ids array in the request body)

Maintain a mapping table of Reamaze_Topic_Slug → Freshservice_Folder_ID and Reamaze_Article_Slug → Freshservice_Article_ID. You will need both for loading articles and rewriting internal links.

Step 3: Transform Content and Re-host Images

Re:amaze article body fields contain HTML. Freshservice article description fields also accept HTML. The transfer sounds simple, but there are real transformation issues.

HTML sanitization: Freshservice accepts standard HTML but strips or reformats certain tags:

• <iframe> embeds — Freshservice strips these in most configurations. Test a single article with an iframe before migrating the full set.
• <script> tags — always stripped.
• Re:amaze Liquid-style variables (e.g., {{ customer.name }}) — render as literal text in Freshservice since it has no equivalent templating system.
• Custom CSS classes — Freshservice may strip inline styles or class attributes.

Image format and size limits: Re:amaze articles may contain large PNGs, GIFs, or WebP images. Freshservice enforces attachment size limits (maximum 20MB per attachment in most plan configurations). Images embedded in Re:amaze articles as large animated GIFs are a common source of upload failures. Audit image sizes before running the migration and convert or compress files exceeding 15MB.

Image re-hosting is the most critical and failure-prone step. Images uploaded to Re:amaze are hosted on their CDN (e.g., https://file.reamaze.com/...). If you push the Re:amaze HTML into Freshservice without rewriting image URLs, the images will render perfectly — until you cancel your Re:amaze account. Then every image across your entire Freshservice KB returns a 404.

You must programmatically parse the HTML of every article, download the images, re-host them, and rewrite the src attributes:

from bs4 import BeautifulSoup
import requests
import boto3
 
s3 = boto3.client('s3')
 
def process_article_images(html_content, article_id):
    soup = BeautifulSoup(html_content, 'html.parser')
    images = soup.find_all('img')
    
    for img in images:
        original_url = img.get('src', '')
        if 'reamaze.com' in original_url:
            response = requests.get(original_url, timeout=30)
            response.raise_for_status()
            file_name = f"article_{article_id}_{original_url.split('/')[-1]}"
            content_type = response.headers.get('Content-Type', 'image/png')
            
            # Check file size before upload
            if len(response.content) > 20 * 1024 * 1024:
                print(f"WARNING: Image {original_url} exceeds 20MB, compressing required")
                continue
            
            s3.put_object(
                Bucket='my-kb-assets',
                Key=file_name,
                Body=response.content,
                ContentType=content_type
            )
            
            new_url = f"https://my-kb-assets.s3.amazonaws.com/{file_name}"
            img['src'] = new_url
            
    return str(soup)

Step 4: Load Articles into Freshservice

The Freshservice article creation endpoint is POST /api/v2/solutions/folders/{folder_id}/articles. Each article requires a folder_id specified in the URL path.

curl -X POST 'https://{domain}.freshservice.com/api/v2/solutions/folders/{folder_id}/articles' \
  -u {api-key}:X \
  -H 'Content-Type: application/json' \
  -d '{
    "title": "How to Process a Return",
    "description": "<p>Sanitized HTML content here...</p>",
    "status": 2,
    "tags": ["migrated-from-reamaze", "migration-2024-01"]
  }'

Key fields:

• title (required) — article title; must be non-empty string
• description (required) — HTML body content; must be non-empty
• status — integer 1 (Draft) or 2 (Published); do not pass as string
• tags — JSON array of strings; use these to tag migrated content for auditing
• folder_id — specified in the URL path, not the body

Author mapping: Freshservice assigns the article to the agent whose API key is used. The Create Article API does not accept an author field. Record original authorship in a tag (e.g., author-jane-smith) or append a metadata block to the article body: <p><em>Originally authored by Jane Smith</em></p>.

Timestamps: Freshservice creates articles with the current timestamp. Original created_at and updated_at from Re:amaze cannot be set via the API. Store original metadata in tags or a separate mapping table if audit trails matter.

For a typical article with two images re-hosted on S3, expect 1 API call per article. At 100 articles, that is 100 calls — well within a single minute window on any paid plan. At 500 articles with rate limit overhead and retries, budget for 10–15 minutes of migration time on Pro (400 req/min). Monitor the X-RateLimit-Remaining header and pause when it drops below 10.

Step 5: Rewrite Internal Links

If Article A in Re:amaze links to Article B, the hyperlink points to something like https://support.yourcompany.com/kb/topic/article-b. After migration, Article B has a completely different URL in Freshservice (https://yourcompany.freshservice.com/support/solutions/articles/{numeric_id}).

To fix internal links:

1. Complete the article migration to generate Freshservice Article IDs.
2. Build a mapping table of Reamaze_Article_Slug → Freshservice_Article_ID.
3. Construct the full Freshservice article URL: https://{domain}.freshservice.com/support/solutions/articles/{article_id}.
4. Run a replacement over the HTML body of all articles to swap old Re:amaze URLs for the new Freshservice URLs.
5. Push corrected HTML using the Freshservice update article endpoint.

The update endpoint is PUT /api/v2/solutions/articles/{article_id}:

curl -X PUT 'https://{domain}.freshservice.com/api/v2/solutions/articles/{article_id}' \
  -u {api-key}:X \
  -H 'Content-Type: application/json' \
  -d '{
    "description": "<p>Updated HTML with corrected internal links...</p>"
  }'

This is a post-import pass — you need the Freshservice article IDs to exist before you can rewrite the links. Run the link rewriting pass after the full article load is complete and validated for count accuracy.

Step 6: Handle Delta Changes Before Cutover

The cutover pattern that minimizes risk:

1. Run a full migration to a Freshservice staging environment or a parallel workspace.
2. Freeze authoring in Re:amaze (communicate this to authors).
3. To identify articles changed since your last extraction, compare updated_at timestamps from a fresh Re:amaze API export against your local staging database. Re:amaze does not provide a changelog endpoint or webhook for article updates — timestamp comparison is the only mechanism.
4. Re-export only changed articles (where updated_at > your last extraction timestamp), transform, and upsert into Freshservice using PUT /api/v2/solutions/articles/{article_id} for existing articles and POST for new ones.
5. Run smoke tests (see Step 7).
6. Switch navigation and publish redirects.
7. Do not run a cutover on a Friday.

Step 7: Validate the Migration

Never trust a migration without validation.

Count validation:

• Total articles extracted from Re:amaze = total articles created in Freshservice
• Total topics extracted = total folders created (or categories, depending on your mapping)
• Verify using GET /api/v2/solutions/articles?per_page=100&tags=migrated-from-reamaze to count migrated articles programmatically

Content validation (sample-based): Pick 10–15% of articles at random. Open each in Re:amaze and Freshservice side by side. Verify:

• Title matches exactly
• Body HTML renders correctly (formatting, lists, code blocks)
• All images load from new URLs (S3 or R2), not the Re:amaze CDN
• Internal links between articles resolve to correct Freshservice URLs

Status and visibility validation:

• All Re:amaze Published articles are Published (status = 2) in Freshservice
• Internal articles (status = 4 in Re:amaze) are in agents-only folders (visibility = 3)
• Draft articles remain in Draft status (status = 1)
• Mixed-status topics have been split into separate public and internal folders

Search validation:

• Search for 5–10 known article titles in the Freshservice self-service portal to confirm they are indexed and discoverable

Access validation — test these paths explicitly:

• Unauthenticated (public) requester view of a public article
• Authenticated requester view of a logged-in-only article
• Agents-only folder — confirm non-agent requesters cannot access
• Department-scoped folder — confirm only assigned-department members can access

A count match is necessary but not sufficient. Discoverability is a large part of the value of any knowledge base — a structurally correct import can still fail if folder choices or missing tags make articles harder to find.

Edge Cases That Break Migrations

Unlisted Articles

Re:amaze Unlisted articles are accessible by direct URL but hidden from FAQ navigation and search. There is no clean 1:1 equivalent in Freshservice. See the three concrete Freshservice patterns documented in the Visibility Mismatch section above.

Multi-Brand FAQ Content

Each Re:amaze brand comes with an independent FAQ site. If your Re:amaze account has multiple brands, you are running multiple independent FAQ sites. Decide upfront whether to merge them into a single Freshservice KB or use Freshservice Workspaces to maintain separation. On Freshservice Starter, there is one workspace. Pro and Enterprise plans support multiple workspaces with separate agent assignments and portal configurations.

Multilingual Content

If your Re:amaze FAQ uses duplicated language topics or separate language brands, normalize that content before import. Freshservice's multilingual knowledge base links secondary-language articles to a primary article using the PUT /api/v2/solutions/articles/{article_id}/translated_versions endpoint. The request body requires language (e.g., "es" for Spanish) and description (translated HTML). A primary-language article must exist before translated versions can be attached.

curl -X POST \
  'https://{domain}.freshservice.com/api/v2/solutions/articles/{primary_article_id}/translated_versions' \
  -u {api-key}:X \
  -H 'Content-Type: application/json' \
  -d '{
    "title": "Cómo procesar una devolución",
    "description": "<p>Contenido HTML traducido...</p>",
    "status": 2,
    "language": "es"
  }'

Freshservice falls back to the primary-language article when a translation does not exist for a requester's language setting. Create all primary-language articles first, then attach translated versions in a second pass.

Embedded FAQ JavaScript Widgets

The Re:amaze inline FAQ is an embeddable version of the standalone Help Site that can be fully integrated into your existing site content and displayed natively via JavaScript SDK. If your website embeds Re:amaze FAQ content using their JavaScript SDK, those widgets stop working after migration. Plan to replace them with Freshservice's self-service portal links or Freshservice's embeddable widget, which provides a subset of the inline FAQ functionality.

Article Ordering

Re:amaze lets you reorganize content with drag-and-drop sorting for both topics and articles. The Re:amaze API does not expose sort order as a retrievable field. Freshservice articles display in the order they are created or as manually reordered in the admin interface. If article order matters, create articles in the desired sequence during the load step. Reordering post-migration requires the Freshservice admin UI — there is no bulk reorder API.

Video Embeds and Iframes

Re:amaze allows arbitrary iframes (YouTube, Loom embeds) in articles. Freshservice's security filters strip unrecognized iframes in most configurations. Before migrating, test a single article with an iframe against your specific Freshservice instance. If iframes are stripped, convert them to thumbnail images with hyperlinks, or use Freshservice's native video embed feature if your plan supports it.

SEO and Redirects

If your Re:amaze knowledge base was public and indexed by search engines, migrating to Freshservice changes all URLs. Re:amaze article URLs follow the pattern https://support.yourcompany.com/kb/{topic-slug}/{article-slug}. Freshservice article URLs follow https://{domain}.freshservice.com/support/solutions/articles/{numeric_id}.

Freshservice does not offer a native URL redirect manager for knowledge base articles. Handle redirects at the DNS/CDN level (Cloudflare Page Rules or Redirect Rules) to map old Re:amaze slugs to new Freshservice article IDs. Build the redirect manifest during migration — you have the slug-to-ID mapping table at that point. After migration, that mapping becomes difficult to reconstruct.

DIY Script vs. Professional Service

This migration is technically straightforward for small knowledge bases — under 50 articles, minimal images, single brand. A senior engineer can write the extraction and loading scripts in a day and validate in another.

Use objective criteria to decide:

Teams that attempt this without preparation frequently hit four specific failure modes:

1. Broken images — failing to re-host before the Re:amaze contract expires. Images appear to work during migration because the CDN is still live, then break 30 days later.
2. Dead internal links — skipping the URL mapping and rewriting pass. Detectable only by clicking through articles manually.
3. Mismatched visibility — using Draft status for internal articles instead of agents-only folders. Internal content becomes visible to agents but flagged as "unfinished."
4. Lost multilingual structure — importing translated articles as independent articles rather than as translated versions of a primary, breaking Freshservice's language fallback behavior.

Think about this migration in three layers: content (articles and images), permissions (status and visibility mapping), and delivery (SEO, redirects, embeds, and portal UX). Content is straightforward. Permissions is where most mapping errors happen. Delivery is where things either survive or break post-launch.

For a deeper look at the planning process, see our Knowledge Base Migration Checklist or our guide on choosing an enterprise KB migration service.

What a Clean Migration Looks Like

A well-executed Re:amaze FAQ to Freshservice KB migration leaves you with:

• Every published article accessible and searchable in the Freshservice self-service portal
• All images hosted on your own infrastructure — no lingering dependencies on Re:amaze CDN
• A clear hierarchy mapping document showing which Re:amaze Topic became which Freshservice Category/Folder
• Migration tags on every article (migrated-from-reamaze, migration date) for auditability and rollback targeting
• Zero broken internal links — verified by the PUT rewriting pass
• Correct folder visibility on every folder — public content at visibility = 1, internal content at visibility = 3
• A redirect manifest deployed at the CDN layer for any SEO-indexed Re:amaze URLs
• Multilingual articles properly linked as translated versions of primary articles, not as standalone duplicates
• No customer-facing downtime — publish in Freshservice first, then decommission Re:amaze

The data model differences between Re:amaze and Freshservice are manageable with a structured approach. The details — image re-hosting before CDN expiry, inter-article link rewriting using the PUT endpoint, status-to-visibility mapping at the folder level, and hierarchy translation with explicit topic extraction — are where clean migrations separate from broken ones.