Migratie van Movable Type naar Next.js voor Japanse bedrijven
Movable Type naar Next.js Migratiegids voor Japanse Bedrijven
Als je enige tijd met Japanse enterprise-websites hebt gewerkt, ben je vrijwel zeker Movable Type tegengekomen. Het CMS van Six Apart heeft sinds het midden van de jaren 2000 een opmerkelijk sterke grip op de Japanse markt, voorzien van alles van bedrijfssites bij grote fabrikanten tot overheidsportals en universiteitswebsites. Maar hier is het ding -- het is 2026, en het web is verder gegaan. Je Movable Type-installatie waarschijnlijk niet.
Ik heb in de afgelopen twee jaar verschillende Japanse enterprise-sites van Movable Type af geholpen migreren, en ik zal eerlijk zijn: het is geen triviaal project. Er zijn eigenaardigheden rond tekencodering, content-structuren uniek voor Japanse bedrijfssites, en organisatorische overwegingen die deze migraties anders maken dan je typische WordPress-naar-Next.js-stap. Deze gids bestrijkt alles wat ik de moeilijke weg heb geleerd.
Inhoudsopgave
- Waarom Japanse Bedrijven Movable Type Verlaten
- Inzicht in Movable Type's Architectuur
- Je Headless CMS Backend Kiezen
- Content Audit en Data Extractie
- Omgang met Japanse Content Specifics
- Het Next.js Frontend Bouwen
- SEO Migratiestrategie voor Japans Zoeken
- Implementatie en Infrastructuur
- Tijdlijn en Budgetplanning
- Veelgestelde Vragen
Waarom Japanse Bedrijven Movable Type Verlaten
Laten we het voor de hand liggende uit de weg ruimen: Movable Type is niet dood. Six Apart Japan onderhoudt het nog steeds, en Movable Type 8 (uitgebracht in laat 2024) voegde enkele moderne functies toe. Maar de handschriften zijn aan de muur voor verschillende redenen.
Prestatiebezorgdheden
Movable Type gebruikt een statisch publicatiemodel -- het herbouwt HTML-bestanden wanneer content verandert. Dit klinkt geweldig totdat je een site met 15.000 pagina's hebt en een content editor die 20 minuten wacht totdat een herbouwing klaar is. Ik heb Japanse bedrijfssites gezien waar editors herbouwingen 's nachts zouden inplannen omdat het proces zo langzaam was.
Next.js met ISR (Incremental Static Regeneration) of on-demand revalidatie lost dit volledig op. Pagina's worden individueel in milliseconden opnieuw gegenereerd.
Eigendomskosten
Movable Type-licenties in Japan kosten ruwweg ¥600.000-¥1.200.000 per jaar voor enterprise-licenties vanaf 2026. Dat is $4.000-$8.000 USD jaarlijks alleen voor de CMS-licentie, voordat hosting, plug-ins of aangepaste ontwikkeling in acht worden genomen. Vergelijk dat met een headless CMS zoals microCMS (populair in Japan, vanaf ¥4.900/maand voor businessplannen) gecombineerd met Next.js op Vercel, en de wiskunde ziet er heel anders uit.
Developer Tekort
Dit is het grote waar niemand publiekelijk over praat. Ontwikkelaars vinden die Perl kennen (Movable Type's taal) en bereid zijn aan MT-templates te werken wordt echt moeilijk in Japan. De mediaanleeftijd van MT-ervaren ontwikkelaars die ik ben tegengekomen is boven de 45. Intussen zijn Next.js-ontwikkelaars overal -- het is het framework dat Japanse tech-bedrijven in 2026 inhuren.
Beveiliging en Compliance
Movable Type heeft in de loop der jaren verschillende serieuze CVE's gehad, inclusief de beruchte XMLRPC-kwetsbaarheid (CVE-2021-20837) die actief werd misbruikt tegen Japanse sites. Met Japans gewijzigd APPI-vereisten (Wet op de Bescherming van Persoonsgegevens) die in 2025-2026 aanscherpen, evalueren bedrijven hun veiligheidssituatie opnieuw.
Inzicht in Movable Type's Architectuur
Voordat je kunt migreren, moet je begrijpen waar je van migreert. Het gegevensmodel van Movable Type verschilt van WordPress of de meeste moderne CMS'en.
Core Data Structures
| MT Concept | Beschrijving | Next.js/Headless Equivalent |
|---|---|---|
| Blog | Top-level content container | Site of workspace |
| Entry | Blogbericht of artikel | Content item (blog type) |
| Page | Statische pagina | Content item (page type) |
| Category | Hiërarchische taxonomie | Category/tag system |
| Template | HTML-templates met MT-tags | React-componenten + layouts |
| Custom Field | Uitgebreide entry-velden | Content model velden |
| Asset | Geüploade mediabestanden | Media/asset library |
| Website | Parent container voor blogs | Multi-site configuratie |
De sjabloontaal van Movable Type gebruikt tags zoals <mt:EntryTitle> en <mt:Entries>. Deze wijzen niet 1-op-1 toe aan iets in de moderne stack -- je bouwt de presentatielaag helemaal opnieuw.
The Database Layer
MT ondersteunt MySQL, PostgreSQL en SQLite. De meeste Japanse enterprise-installaties gebruiken MySQL. Het databaseschema is goed gedocumenteerd maar... eigenwijs. Aangepaste velden worden opgeslagen in een aparte mt_entry_meta-tabel met een sleutel-waarde-patroon, wat extractie niet-triviaal maakt.
Hier is hoe de entry-tabel eruit ziet:
SELECT
entry_id,
entry_title,
entry_text,
entry_text_more,
entry_excerpt,
entry_created_on,
entry_modified_on,
entry_basename,
entry_status
FROM mt_entry
WHERE entry_blog_id = 1
AND entry_status = 2 -- 2 = published
ORDER BY entry_created_on DESC;
Merk de entry_text en entry_text_more split op. MT verdeelt body content in twee velden -- een patroon uit het vroege bloggen dat je moet samenvoegen tijdens migratie.
Je Headless CMS Backend Kiezen
Next.js is je frontend-framework. Maar je hebt ergens een plek nodig om content te beheren. Voor Japanse bedrijven heb ik het beperkt tot vier realistische opties.
microCMS
Dit is de standaardkeuze voor Japanse bedrijven, en met reden. Het wordt gebouwd door een Japans bedrijf, heeft een native Japanse UI, Japanse klantondersteuning, en gegevensresidentie in Japan. De prijsstelling begint bij ¥4.900/maand (Hobby is gratis voor kleine projecten). De API is schoon, de webhook-ondersteuning werkt goed met Next.js ISR, en je content editors hoeven geen Engels.
Newt
Een ander door Japan gemaakte headless CMS dat aan kracht wint. Het is iets meer developer-vriendelijk dan microCMS en heeft betere flexibiliteit voor content-modellering. Goede optie als je site complexe content-structuren heeft.
Contentful
De globale enterprise-keuze. Sterke lokalisatieondersteuning, uitstekende API, en een volwassen ecosysteem. Het nadeel voor Japanse bedrijven: ondersteuning is in het Engels, de UI is in het Engels, en prijzen zijn in USD. Met $300/maand voor het Team-plan (2026-prijzen), is het aanzienlijk duurder dan Japanse alternatieven.
Sanity
Ik noem Sanity omdat het technisch uitstekend is en de aanpasbare Studio met Japanse labels kan worden geconfigureerd. Maar de leerkromme is steiler, en je zult niet veel Japanse ontwikkelaars met Sanity-ervaring vinden.
| CMS | Japanse UI | Japan Data Residency | Startprijs | Best Voor |
|---|---|---|---|---|
| microCMS | ✅ | ✅ | ¥4.900/ma | De meeste Japanse bedrijfssites |
| Newt | ✅ | ✅ | ¥3.300/ma | Complexe content-modellen |
| Contentful | ❌ | ❌ (EU/US) | ~$300/ma | Globale ondernemingen |
| Sanity | Gedeeltelijk | ❌ | $99/ma (Team) | Developer-zware teams |
Voor de meeste Japanse bedrijven die van Movable Type migreren, beveel ik microCMS of Newt aan. De frictiereductie van alles in het Japans hebben is meer waard dan je zou denken. We hebben uitgebreid met al deze gewerkt door onze headless CMS-ontwikkelingspraktijk.
Content Audit en Data Extractie
Dit is waar het echte werk begint. Sla de audit-fase niet over -- ik heb migraties zien mislukken omdat teams rechtstreeks naar extractie sprongen zonder te begrijpen wat ze eigenlijk hadden.
Stap 1: Inventariseer Alles
Maak verbinding met je MT-database en voer tellingen uit:
-- Count entries by blog
SELECT
b.blog_name,
COUNT(e.entry_id) as entry_count
FROM mt_entry e
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
WHERE e.entry_status = 2
GROUP BY b.blog_name;
-- Count custom fields per blog
SELECT
b.blog_name,
em.entry_meta_type,
COUNT(*) as field_count
FROM mt_entry_meta em
JOIN mt_entry e ON em.entry_meta_entry_id = e.entry_id
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
GROUP BY b.blog_name, em.entry_meta_type;
Stap 2: Export Content
MT heeft een ingebouwde exportindeling, maar deze is beperkt. Ik geef de voorkeur aan rechtstreekse database-extractie met een Python-script:
import mysql.connector
import json
import html
def extract_mt_entries(config):
conn = mysql.connector.connect(**config)
cursor = conn.cursor(dictionary=True)
cursor.execute("""
SELECT
e.entry_id,
e.entry_title,
e.entry_text,
e.entry_text_more,
e.entry_excerpt,
e.entry_basename,
e.entry_created_on,
e.entry_modified_on,
GROUP_CONCAT(c.category_label) as categories
FROM mt_entry e
LEFT JOIN mt_placement p ON e.entry_id = p.placement_entry_id
LEFT JOIN mt_category c ON p.placement_category_id = c.category_id
WHERE e.entry_status = 2
GROUP BY e.entry_id
""")
entries = cursor.fetchall()
for entry in entries:
# Combine text and text_more
body = (entry['entry_text'] or '') + (entry['entry_text_more'] or '')
entry['full_body'] = body
# Handle encoding
entry['entry_title'] = entry['entry_title']
with open('mt_export.json', 'w', encoding='utf-8') as f:
json.dump(entries, f, ensure_ascii=False, default=str, indent=2)
return entries
Stap 3: Media Asset Migratie
MT slaat assets op het bestandssysteem op, meestal onder /path/to/mt/support/uploads/. Je moet:
- Alle bestanden inventariseren en ze afstemmen met databaserecords in
mt_asset - Opnieuw uploaden naar je nieuwe CMS of een CDN (Cloudinary, imgix, of de ingebouwde opslag van je CMS)
- Alle verwijzingen in je content body HTML bijwerken
Dit is vervelend. Budget tijd voor.
Omgang met Japanse Content Specifics
Dit gedeelte is waarom ik dit artikel heb geschreven. Generieke migratiegidsen dekken deze problemen niet.
Tekencodering
Oudere Movable Type-installaties (pre-MT5) slaagden soms content op in EUC-JP of Shift_JIS-codering, zelfs als de database nominaal UTF-8 was. Controleer je werkelijke gegevens:
# Detect encoding issues
import chardet
def check_encoding(text_bytes):
result = chardet.detect(text_bytes)
if result['encoding'] != 'utf-8':
print(f"Warning: detected {result['encoding']} "
f"with {result['confidence']:.0%} confidence")
return result
Als je coderingsfouten vindt, converteer alles naar UTF-8 voordat je in je nieuwe CMS importeert. Onderbroken mojibake (文字化け) op een bedrijfssite is een carrière-limiterende gebeurtenis.
Ruby Text (Furigana)
Japanse bedrijfssites gebruiken frequent ruby-aantekeningen -- kleine leeshulpen boven kanjikarakters. MT-sjablonen behandelen deze vaak met aangepaste tags. In Next.js gebruik je standaard HTML <ruby>-elementen:
// components/RubyText.tsx
export function RubyText({ base, reading }: { base: string; reading: string }) {
return (
<ruby>
{base}
<rp>(</rp>
<rt>{reading}</rt>
<rp>)</rp>
</ruby>
);
}
Zorg ervoor dat je content-migratiescript bestaande ruby-markup behoudt.
Japanse Datumaanduiding
Japanse bedrijfssites geven data vaak weer in 和暦 (Japans era-formaat): 令和8年1月15日 in plaats van 2026-01-15. Handel dit af in je Next.js-componenten:
function formatJapaneseDate(dateString: string): string {
const date = new Date(dateString);
return date.toLocaleDateString('ja-JP-u-ca-japanese', {
era: 'long',
year: 'numeric',
month: 'long',
day: 'numeric',
});
}
Verticale Tekstlay-outs
Sommige Japanse sites, vooral in uitgeverij of traditionele industrieën, gebruiken verticale tekst (縦書き). CSS handelt dit af:
.vertical-text {
writing-mode: vertical-rl;
text-orientation: mixed;
}
Next.js handelt dit prima af, maar test goed in alle browsers.
Het Next.js Frontend Bouwen
Met je content geëxtraheerd en je CMS gekozen, is het tijd om te bouwen. Hier is de architectuur die ik aanbeveel voor Japanse bedrijfssites.
App Router met Statische Generatie
Gebruik Next.js 15's App Router met statische generatie voor de meeste pagina's. Japanse bedrijfssites zijn typisch content-zwaar met onfrequente updates -- perfect voor statische generatie met on-demand revalidatie.
// app/news/[slug]/page.tsx
import { getArticle, getAllArticleSlugs } from '@/lib/cms';
export async function generateStaticParams() {
const slugs = await getAllArticleSlugs();
return slugs.map((slug) => ({ slug }));
}
export default async function NewsArticle({
params
}: {
params: Promise<{ slug: string }>
}) {
const { slug } = await params;
const article = await getArticle(slug);
return (
<article>
<h1>{article.title}</h1>
<time dateTime={article.publishedAt}>
{formatJapaneseDate(article.publishedAt)}
</time>
<div dangerouslySetInnerHTML={{ __html: article.body }} />
</article>
);
}
i18n Configuratie
Veel Japanse bedrijfssites hebben zowel Japanse als Engelse versies nodig. Next.js App Router handelt dit af met routegroepen of middleware-gebaseerde locale-detectie:
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
const pathname = request.nextUrl.pathname;
const locale = pathname.startsWith('/en') ? 'en' : 'ja';
request.headers.set('x-locale', locale);
return NextResponse.next();
}
We hebben tientallen tweetalige Japanse bedrijfssites gebouwd met Next.js -- ons Next.js-ontwikkelingsteam kan je door de nuances lopen.
SEO Migratiestraategie voor Japans Zoeken
Dit is niet onderhandelbaar. Japanse bedrijven leven en sterven door hun Google-zoekrankings (Yahoo! Japan gebruikt Google's engine, dus het gaat echt alleen om Google). Een verpeste migratie kan je organische verkeer maandenlang verwoesten.
URL Mapping
Movable Type genereert URL's met configureerbare patronen. Veelvoorkomende die ik op Japanse sites zie:
/blog/2024/01/entry-basename.html/news/category/entry_basename.html/archives/000123.html(het oudste patroon)
Maak volledige URL-mapping voordat je iets bouwt:
// scripts/generate-redirects.ts
interface RedirectMap {
source: string;
destination: string;
permanent: boolean;
}
function generateRedirects(mtEntries: MTEntry[]): RedirectMap[] {
return mtEntries.map(entry => ({
source: buildMTUrl(entry), // Old MT URL pattern
destination: `/news/${entry.entry_basename}`, // New Next.js URL
permanent: true, // 301 redirect
}));
}
Zet deze in je next.config.ts:
const nextConfig = {
async redirects() {
const redirects = await import('./redirects.json');
return redirects.default;
},
};
Voor sites met duizenden redirects, gebruik in plaats daarvan middleware -- next.config.ts redirects hebben een praktische limiet.
Structured Data
Japanse Google-resultaten kenmerken zich zwaar met rijke snippets. Voeg JSON-LD toe voor artikelen, veelgestelde vragen, en organisatie-info:
function ArticleJsonLd({ article }: { article: Article }) {
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: article.title,
datePublished: article.publishedAt,
dateModified: article.updatedAt,
author: {
'@type': 'Organization',
name: article.companyName,
},
inLanguage: 'ja',
};
return (
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
);
}
Implementatie en Infrastructuur
Voor Japanse doelgroepen is latentie belangrijk. Hier is wat werkt:
| Platform | Japan Edge Nodes | Best Voor | Maandelijkse Kosten (typisch) |
|---|---|---|---|
| Vercel | Tokio | De meeste Next.js-sites | $20-150/ma |
| AWS (CloudFront + Lambda@Edge) | Tokio, Osaka | Enterprise compliance | $100-500/ma |
| Google Cloud Run + Cloud CDN | Tokio | GCP-native teams | $50-200/ma |
| Cloudflare Pages | Tokio + veel | Eenvoudige statische sites | Gratis-$25/ma |
Vercel is mijn standaardaanbeveling. Het is speciaal gemaakt voor Next.js, heeft een edge node in Tokio, en de DX is ongeëvenaard. Voor bedrijven met strikte gegevensresidentievereisten (overheid, financieel), is AWS in ap-northeast-1 (Tokio) de veilige keuze.
Als je in plaats van Next.js Astro overweegt voor een content-zware site met minimale interactiviteit, dat is een geldige keuze ook -- controleer onze Astro-ontwikkelingsmogelijkheden.
Tijdlijn en Budgetplanning
Op basis van werkelijke migraties die ik heb voltooid, is dit wat je kunt verwachten:
| Fase | Duur | Belangrijkste Activiteiten |
|---|---|---|
| Discovery & Audit | 2-3 weken | Content-inventaris, belanghebbendengesprekken, URL-mapping |
| CMS Setup & Content Modeling | 2-4 weken | Schema-ontwerp, content-migratiescripts |
| Content Migratie | 3-6 weken | Gegevensoverdracht, media-migratie, QA |
| Frontend Development | 6-10 weken | Next.js-build, componentbibliotheek, i18n |
| SEO & QA | 2-3 weken | Redirect-testen, prestatieafstelling, cross-browser QA |
| Gefaseerde Rollout | 1-2 weken | DNS-cutover, monitoring, hotfixes |
Totaal: 16-28 weken voor een typische Japanse bedrijfssite met 1.000-10.000 pagina's.
Budget-wise, je kijkt naar ¥5.000.000-¥15.000.000 ($33.000-$100.000 USD) afhankelijk van complexiteit. Dat kan een heleboel lijken, maar overweeg: je betaalt waarschijnlijk al ¥1.000.000+ jaarlijks voor MT-licenties en gespecialiseerde ontwikkeling. De migratie betaalt zichzelf terug binnen 2-3 jaar door verminderde operationele kosten en verbeterde developer velocity.
Heb je een gedetailleerde schatting nodig voor jouw specifieke situatie? Neem contact op of bekijk onze prijzenpagina voor engagement-modellen.
Veelgestelde Vragen
Kunnen we Movable Type blijven gebruiken als een headless CMS met Next.js? Technisch ja -- Movable Type 7+ heeft een Data API die content naar een frontend kan serveren. Maar het is langzaam, slecht gedocumenteerd, en mist webhooks voor revalidatie. Ik heb deze benadering op één project geprobeerd en zou het niet aanraden. Je zult meer tijd besteden aan het omgaan met MT's API-beperkingen dan je zou doen migreren naar een goede headless CMS.
Hoe gaan we met het MT-herbouw-model tegen Next.js ISR om? Ze zijn fundamenteel anders. MT bouwt hele sitesecties tegelijk opnieuw (batch statische generatie). Next.js ISR genereert individuele pagina's on-demand opnieuw. Dit betekent dat je editors onmiddellijke publicatietijden krijgen in plaats van te wachten op herbouwingen. De gedachte-modelverandering is eigenlijk gemakkelijker voor editors -- ze drukken gewoon op publiceren en de pagina is binnen seconden live.
Wat gebeurt er met onze MT-plug-ins tijdens migratie? Elke MT-plug-in heeft een vervanger of herimplementatie nodig. Veelvoorkomende zoals contactformulieren (MT-gebaseerde formulierplug-ins) worden vervangen door Next.js-formulierverwerking of services zoals Formspree. Search-plug-ins worden vervangen door Algolia of de ingebouwde zoekopdracht van de CMS. Maak een complete plug-in-inventaris tijdens de audit-fase.
Zullen onze Google-rankings dalen tijdens migratie? Ze kunnen, maar dat hoeft niet. De kritieke factoren zijn: 301-omleidingen voor elke URL, onderhoud van identieke of verbeterde paginatitels en meta-beschrijvingen, behoud van interne linkstructuur, en indiening van een bijgewerkte sitemap. Ik heb migraties gezien waarbij de rankings eigenlijk verbeterden omdat de nieuwe site sneller was en betere Core Web Vitals scores had.
Hoe gaan we met Japanse-specifieke SEO-elementen om zoals Yahoo! Japan? Yahoo! Japan gebruikt sinds 2010 Google's zoekengine, dus je Google SEO-strategie dekt Yahoo! ook. De enige uitzondering zijn Yahoo! Japan's eigen eigenschappen (Yahoo! News, enz.) die aparte inzendingsprocessen hebben. Voor algemeen organisch zoeken, focus op Google en je bent gedekt.
Moeten we alle content migreren of dit als gelegenheid gebruiken om op te ruimen? Altijd opruimen. In elke Japanse bedrijfssite-migratie die ik heb gedaan, was 30-50% van de content verouderd, redundant, of had nul verkeer. Het migreren van dode content verspilt tijd en verzwakt je siteverificatie van topicale autoriteit. Gebruik analyticsgegevens om pagina's te identificeren die het waard zijn te migreren en laat de rest gaan (met geschikte 410 Gone-reacties, geen 404's).
Kunnen we Movable Type en Next.js parallel uitvoeren tijdens migratie? Ja, en ik beveel het aan. Gebruik een subdomein of pad-gebaseerde routing om de nieuwe Next.js-site voor gemigreerde secties uit te voeren terwijl MT de rest afhandelt. Dit laat je in fasen migreren in plaats van een riskante big-bang cutover. Reverse proxy-configuraties met nginx of Cloudflare Workers maken dit eenvoudig.
Wat zit Movable Type's ingebouwde toegangscontrole en ledenfeatures? Als je MT-site lid-login, gated content, of op rol gebaseerde toegang gebruikt, moet je authenticatie in Next.js implementeren. Auth.js (voorheen NextAuth.js) werkt goed hiervoor, of je kunt een service zoals Clerk of Auth0 gebruiken. Dit voegt complexiteit en kosten toe -- factor het van dag één in je planning in.