Case Study
View Case StudyTray.ai
Migrating hundreds of thousands of pages, re-platforming and extending for the leading composable AI integration platform
From Builder.io to Directus
We are the Builder.io to Directus migration experts
Last verified:
Challenges with Builder.io
Key pain points
Builder.io looks impressive in demos but the reality of day-to-day usage tells a different story. The editor can be laggy, especially with more than 30 components on a page, and we have seen reports of outright crashes that lose unsaved work. The documentation is a persistent sore point. Developers on forums describe spending days trying to get basic integrations working because the docs are outdated or incomplete. For an agency setting up projects for clients, unreliable documentation means unpredictable timelines.
Pricing is another area where Builder.io catches teams off guard. The free tier exists but is quite limited, and costs ramp up quickly once you need features like roles, scheduling, or higher usage limits. We have seen complaints from freelancers and small teams about unexpected charges and slow support response times when trying to resolve billing issues. The lack of self-hosting is also a hard blocker for some clients with strict data residency requirements.
The biggest concern from our perspective is vendor lock-in. Builder.io's SDKs are deeply embedded in your frontend code, and if you ever need to migrate away, you are essentially rebuilding your page composition layer from scratch. There is also no real-time collaboration, so two editors working on the same page can overwrite each other's changes without warning.
Editor performance and stability
The visual editor becomes laggy with complex pages and has been reported to crash, losing unsaved work. Teams with content-heavy pages will feel this friction daily.
Outdated and incomplete documentation
Developers consistently report that the docs are confusing, outdated, or missing critical steps. Getting started takes far longer than it should for a tool that sells itself on speed.
Vendor lock-in risk
Builder.io's SDKs are tightly coupled to your frontend. Migrating away means rebuilding your entire page building and composition layer from scratch.
Limited collaboration tools
Builder.io now offers branching and peer review workflows in its Fusion product, but true real-time co-editing is still missing. Editors working outside of the Projects workflow can still overwrite each other's changes.
Pricing escalation
Costs ramp up quickly beyond the free tier, and teams report unexpected charges. Basic features like roles and scheduling sit behind higher-priced plans.
Slow and unresponsive support
Multiple users report delayed support responses, unresolved tickets, and difficulty getting refunds or cancellations processed in a reasonable timeframe.
Benefits of Directus
Key advantages
Directus instantly wins points with us because, well… it has a rabbit for a logo. But beyond that, it's genuinely a solid database-first CMS. If you like the idea of a CMS that sits directly on top of your SQL database without any abstractions, Directus feels incredibly natural.
You can self-host it, tweak it endlessly, and treat your schema exactly the way you want. Editors get a no-code admin UI that feels polished, developers get REST and GraphQL out of the box, and teams get workflows, versioning, automations, and proper permission controls. It's flexible, fast, and a great fit if your content is really just structured data waiting for a smarter interface. If your project revolves around relational data and you want total control from database to API, Directus is one of the cleanest ways to build it.
Intuitive non-technical interface
Editors get a clean, no-code admin panel that feels more like a productivity tool than a CMS. Non-technical teams can handle content updates without pinging developers every five minutes.
Database-agnostic SQL integration
Directus plugs straight into your SQL database and turns it into an API instantly. If your data lives in Postgres, MySQL, MariaDB, or SQLite, it just works.
Field-level permission controls
You can lock down every field, table, and action with granular role-based permissions. Perfect for teams that care about security and don't want interns accidentally deleting production data.
Built-in REST/GraphQL support
Your entire database is instantly exposed as both REST and GraphQL endpoints. Just plug into your frontend and start shipping.
Extensive UI customization
Directus lets you tweak the interface, add custom views, tailor layouts, and build the exact editing experience your team needs. It feels like a CMS you can actually shape instead of fight.
Real-time collaborative editing
Multiple contributors can work in the Studio at the same time without stepping on each other's toes. Collaborative editing shipped in February 2026, so drafts stay clean and the whole workflow feels built for modern teams, not 2010 intranets.
AI Assistant with image and PDF support
The built-in AI Assistant can process images and PDFs as well as text, and it works across OpenAI, Anthropic, and Google Gemini. It's a genuinely useful addition rather than a feature-list checkbox.
Common questions
Builder.io to Directus migration FAQs
Answers to the most common questions about Builder.io to Directus migration
Can you migrate from Builder.io without losing your page designs?
Yes, but it takes work. Builder.io's visual editor stores page compositions as JSON that references your registered components. Those component registrations are tightly coupled to Builder's SDK, so you can't just export and import elsewhere. What you can preserve is the design itself. We extract the page structures, map them to equivalent components in the new system, and rebuild the composition layer. The visual output stays the same. Typical timeline is 6-10 weeks depending on how many page types and custom components are involved. The biggest time sink is usually recreating A/B test variants and personalisation rules that lived inside Builder's platform.
What does Builder.io actually cost?
Builder.io's free tier gives you 1 user and basic features, which is enough to evaluate but not to run a real project. The Growth plan starts at $49/month and includes more seats and content types. Beyond that, pricing gets opaque. Teams needing roles, scheduling, and higher API limits are pushed toward custom Enterprise plans that typically start in the $500-$1,000/month range. We've heard from freelancers and small agencies who were caught off guard by charges after exceeding limits on the Growth plan. Builder.io also charges per "impression" on higher tiers, which means your costs scale with traffic in ways that aren't always predictable.
How does Builder.io compare to a traditional headless CMS?
Builder.io is a visual page builder first and a CMS second. That distinction matters. If your primary goal is letting marketing teams build landing pages without developer involvement, Builder.io does that well. If you need structured content modelling, editorial workflows, multi-language support, or content that powers more than just web pages, a traditional headless CMS is a better fit. Builder.io's SDK embeds deeply into your frontend code, which creates vendor lock-in that most headless CMS platforms avoid. We typically recommend Builder.io only when the use case is narrow: high-volume landing page creation for marketing teams. For everything else, a headless CMS with a proper content model gives you more flexibility long-term.
What's the main risk of building on Builder.io?
Vendor lock-in. Builder.io's SDKs are woven into your component rendering layer, which means migrating away requires rebuilding how your pages are composed and rendered. That's not a content migration, it's an architecture migration. With a typical headless CMS, your content is accessible through standard APIs and your frontend is independent. With Builder.io, the two are intertwined. We've worked with teams who spent months extracting themselves from Builder.io because every page template needed to be recreated outside the platform. If you're evaluating Builder.io, go in with eyes open about the exit cost.
How do we migrate content out of Directus?
Directus sits directly on your SQL database, which is both a blessing and a curse during migration. The blessing is that your content is in standard PostgreSQL, MySQL, or SQLite tables, so extraction is as simple as SQL queries. The curse is that Directus stores relational data and file references in its own conventions, so you need to untangle junction tables and re-map asset URLs. We write custom migration scripts for each project. A typical Directus migration with 50 to 100 content types takes 3 to 5 weeks.
Why do teams move away from Directus?
The two biggest triggers we see right now are licensing uncertainty and pricing sticker shock. Directus moved to the Monospace Sustainable Core License (MSCL) with v12 in May 2026, replacing the old BSL. Organisations under $5M revenue and 50 employees get a free Innovation Grant, but even above those thresholds the MSCL still permits free use of the Core tier — so larger orgs aren't categorically forced onto paid plans, though many opt into the cloud or a commercial self-hosted license for the production features sitting outside Core, and the community is noticeably split, with some teams forking old versions or migrating off entirely. On the cloud side, the old unlimited tier is gone; the Professional plan is $99/month and caps you at 5 users, 75K database entries, and 250K API requests. Growth past those limits means a jump straight to custom Enterprise pricing. On the development side, any custom interface work still requires Vue.js, which creates friction for React-focused teams. Breaking changes between updates also erode trust over time. Teams that started with Directus for its open-source appeal often outgrow it when they need predictable pricing and cleaner editorial workflows.
Can we keep our existing database when migrating from Directus?
You can keep your database infrastructure, but you'll likely restructure the schema. Directus creates its own system tables (directus_users, directus_permissions, directus_files, etc.) alongside your content tables. During migration, we extract the content tables, transform the data to fit your new CMS's content model, and leave the Directus system tables behind. If you're moving to a headless CMS like Sanity, the data moves from SQL rows to structured JSON documents, which typically results in a cleaner content model.
Get in touch
Fill out the form below and we'll get back to you
