Teams rarely leave Remotion because it’s bad — they leave because their product outgrew it. Users started asking to edit videos, not just watch them. Rendering bills started scaling. A mobile app appeared on the roadmap. The words “add captions” entered a sprint planning.
If that’s your situation, the good news: Remotion to Meishe isn’t a demolition project. The concepts map cleanly, and there are four paths — three of which don’t require abandoning Remotion at all.
First, the Concept Map
The mental models differ — Remotion is a React framework; Meishe is an engine with APIs, JSON, and a UI — but the core nouns translate almost one-to-one:
| Meishe Web SDK | Remotion | Note |
|---|---|---|
| Project / timeline | Composition | The video being described |
| JSON payload | React props | Data flowing into the video |
| Track & clip structure | Component tree | Clips on tracks over time |
| Timeline position | useCurrentFrame() | “What moment is rendering now” |
| Keyframes + Bézier curves | spring() / interpolate() | Animation, code vs timeline-based |
| Clip in/out points | <Sequence> | When something exists on the timeline |
| Embedded editor UI | Remotion Player | Preview vs full editing |
| Batch rendering | Server render (Lambda) | Automated output |
The deepest shift: Remotion describes video in code; Meishe describes video in data. A Remotion composition is a React component (an executable program); a Meishe project is JSON (a declarative document). That difference is why Meishe projects can travel to mobile and why non-developers can author them — and it’s the thing your migration actually migrates.
Path 1: Template Conversion (The Common Case)
Most Remotion deployments are template machines: data in, personalized videos out. Migrating that is mechanical:
- Pick one template — your simplest high-volume one, not the flagship.
- Map its structure to JSON: which clips, which text fields, which timings. Remotion props become JSON fields almost directly —
title,logoUrl,scenes[]survive as-is; you’re re-describing, not redesigning. - Rebuild the composition once as a Meishe project (in the editor, or via the API from your template spec).
- Point your data pipeline at the JSON renderer: where you posted props to a render job, you now post JSON to Meishe’s rendering pipeline — output lands back in your storage either way.
What you gain immediately: rendering moves from headless-Chrome frame capture to an engine pipeline, and your template becomes editable in the editor instead of only in code.
Path 2: Keep Remotion, Add Meishe (Hybrid)
If Remotion automation works and the new requirement is an editor — don’t migrate at all. Add:
- Meishe for interactive editing: embed the editor where users touch videos
- Remotion for background automation: existing pipelines untouched
- Bridge via JSON: editor drafts export as JSON; if a draft needs template-style mass variants, feed its JSON to whichever renderer fits the job
This is the lowest-risk path and a permanent architecture, not a stopgap — plenty of products reasonably run a code-native render path and an interactive path.
Path 3: Gradual Replacement
For teams that want one system eventually but can’t stop the line:
- New features land on Meishe (editor features, AI, mobile drafts)
- Existing Remotion templates convert opportunistically — one per sprint, using Path 1’s recipe
- Retire Remotion when template count hits zero — or never, if the hybrid split settles into something comfortable
Path 4: Full Rewrite (Rare, Usually Unnecessary)
Worth it only when the React codebase itself is the problem — inherited, brittle, nobody left who understands it. In that case treat it as a greenfield Meishe integration, not a migration: design the project format first, port content second.
What Porting Actually Looks Like: Props → JSON in Practice
A concrete taste. A Remotion template with props like:
title, subtitle, scenes: [{ clipUrl, duration, caption }]becomes Meishe JSON describing the same shape: a clip per scene on the main track, text overlays with timings, durations carried over. The JSON examples in the docs show real payloads — the structure will look familiar within minutes, because describing “what’s on screen when” is describing “what’s on screen when” in either format.
The part that doesn’t port mechanically: animation authored in code (spring() chains, useCurrentFrame() math). Two options — rebuild the motion as timeline keyframes in the editor, or automate keyframe generation via API for repetitive patterns. Either is usually an afternoon per template, and often the animations get better, because designers can now tweak curves visually instead of asking a developer to change numbers.
A Rollout Plan That Avoids Regret
- Week 1: Embed the editor in a staging page; port one template via Path 1. Measure nothing — just feel it.
- Week 2: Wire the JSON pipeline end-to-end for that template in production shadow mode.
- Week 3–4: Cut over the one template. Watch real outputs, real render performance, real costs.
- Then decide with evidence: full migration, hybrid, or gradual — the one-template experiment prices the rest.
Leaving a tool that taught the market programmatic video feels dramatic. In practice it’s a port, a bridge, or a parallel run — and usually the moment the roadmap unblocks itself.