# KeystoneJS to Drupal migration > How to migrate from KeystoneJS to Drupal, with a side-by-side comparison and FAQs. --- ## Source: KeystoneJS - **Type:** headless - **Official site:** https://keystonejs.com - **Last reviewed:** 2026-07-28 ## Key advantages KeystoneJS is one of those tools that really clicks if your team thinks in code. It's a schema-driven, open-source headless CMS built on Node.js, and the developer experience is genuinely good. You define your content models in TypeScript, Keystone generates a GraphQL API and an admin UI for you, and you're off. There's very little magic or abstraction hiding what's happening under the hood, which we appreciate when building complex projects for clients. The Prisma ORM integration is a real highlight. Automatic migration generation, type-safe database access, and support for PostgreSQL, MySQL, and SQLite mean you're not fighting your data layer. If you've ever had to wrangle a CMS into supporting a non-trivial relational content model, you'll understand why this matters. Keystone lets you express those relationships cleanly and query them with a proper GraphQL API. The document field editor is also worth mentioning. It's one of the more thoughtful rich text implementations we've seen in a headless CMS. You can embed custom React components directly into the editor, which means content teams can work with your actual design system components rather than generic blocks. For teams that care about structured content, Keystone gives you real tools to enforce it. Where Keystone really shines is in projects where the development team wants full ownership of the stack. There's no vendor lock-in, no proprietary query language, and no surprise pricing tiers. If you want a CMS that feels like a well-designed library rather than a platform, Keystone delivers on that promise. ### Schema-as-code with full TypeScript support Define your entire content model in TypeScript with strong type inference throughout. The schema drives everything from the database to the admin UI to the GraphQL API. ### Automatic GraphQL API generation Every content type you define automatically gets a full CRUD GraphQL API with filtering, pagination, and relationship resolution. No manual endpoint wiring needed. ### Prisma-powered database layer Built on Prisma ORM with automatic migration generation and type-safe queries. Supports PostgreSQL, MySQL, and SQLite out of the box. ### Flexible document field editor The rich text editor supports custom embedded components that map to your design system, giving content editors structured authoring without sacrificing flexibility. ### Granular access control Fine-grained, field-level access control defined in code. You can write custom logic for create, read, update, and delete operations per field or per list. ### Fully open source with no vendor lock-in MIT licensed with no paid tiers or proprietary features gated behind a subscription. You own the entire stack and can host it wherever you want. ## Key pain points The biggest challenge with KeystoneJS is that it hands you all the responsibility that a managed CMS would normally handle. Deployment is entirely on you, and the documentation around production hosting, Docker configuration, and scaling is thin. We've seen teams struggle to go from a smooth local development experience to a reliable production setup, especially if they don't have dedicated DevOps support. The admin UI Docker image alone can balloon to over a gigabyte, which is a headache for containerised deployments. The community around Keystone is significantly smaller than competitors like Strapi or Payload. That means fewer tutorials, fewer plugins, and slower answers when you hit an edge case. The ecosystem of ready-made integrations is almost non-existent, so you'll be building most things from scratch. For an agency working on client projects with deadlines, that time cost adds up quickly. Content editors also tend to have a harder time with Keystone compared to more polished alternatives. The admin UI is functional but feels utilitarian, and non-technical users often need more onboarding than you'd expect. There's no visual editing, no preview infrastructure, and no real content workflow features like drafts, publishing schedules, or approval chains without building them yourself. If your client's content team needs a CMS they can pick up and run with, Keystone usually isn't the answer. ### Deployment complexity Self-hosting is the only option, and the docs don't hold your hand. Getting Keystone into production requires real infrastructure knowledge, and the large Docker image sizes make it worse. ### Small community and ecosystem Compared to Strapi or even Payload, the community is much smaller. Fewer plugins, fewer tutorials, and slower support when things go wrong. ### No built-in content workflows There are no turnkey drafts, scheduled publishing, or approval chains. Keystone provides field primitives that can be assembled into publishing workflows, but you need to wire them up yourself. ### Admin UI feels dated The admin panel is functional but lacks the polish and UX of modern CMS interfaces. Non-technical editors often find it confusing and need more training. ### No visual editing or live preview There's no way for editors to see content in context before publishing. You'd need to build your own preview infrastructure, which is a significant engineering effort. ### Scaling requires significant effort Running Keystone under high traffic means managing session stores, reverse proxies, and server resources yourself. It doesn't scale as smoothly as cloud-native CMS alternatives. ## Target: Drupal - **Type:** hybrid - **Official site:** https://www.drupal.org - **Last reviewed:** 2026-07-28 ## Key advantages We'll give credit where it's due: Drupal is a serious CMS for serious projects. If you're building a government portal, a university website, or a massive multilingual platform that needs to serve content in 24 languages, Drupal is genuinely hard to beat. Its content modeling is incredibly deep, its permissions system is enterprise-grade, and its multilingual capabilities are the best in the open-source CMS world. The European Commission runs on it for a reason. Where Drupal really shines is in complex, structured content architectures. You can model relationships between content types, build granular taxonomies, and set up editorial workflows that would make other CMS platforms weep. If your content team has 50 editors across multiple departments with different access levels, Drupal handles that without breaking a sweat. It's also one of the few traditional CMS platforms that has genuinely embraced decoupled architecture, so you can use it as a headless backend with a modern frontend framework if you want. The community is smaller than WordPress but significantly more technical. Drupal developers tend to be proper engineers, and the ecosystem reflects that. Module quality is generally higher, security patches are taken seriously, and the project has strong governance. If you're in an enterprise or government context where compliance, accessibility, and security auditing matter, Drupal is a well-trodden path. That said, we'd only recommend Drupal for projects that genuinely need its power. If you're building a marketing site or a blog, you're using a sledgehammer to hang a picture frame. Talk to us first, and we'll figure out if Drupal is actually the right fit or if you've been sold on it by someone who bills by the hour. ### Exceptional content modeling Drupal's entity and field system lets you build deeply structured, relational content architectures that most CMS platforms can only dream of. Complex taxonomies, references, and custom types are all first-class citizens. ### Best-in-class multilingual support With over 90 languages available out of the box and proper translation workflows baked in, Drupal is the gold standard for multilingual sites. No plugins, no hacks, just native support that actually works. ### Granular permissions and workflows The access control system is absurdly detailed. You can lock down roles, content types, fields, and editorial workflows with a precision that enterprise clients genuinely need and other platforms struggle to match. ### Viable headless architecture Drupal's JSON:API and GraphQL modules make it a legitimate headless CMS option, letting you pair its deep content backend with a modern frontend framework like Next.js or Nuxt. ### Strong security track record The Drupal security team is proactive and well-organized. Security advisories are clear, patches are timely, and the community takes vulnerabilities seriously, which matters a lot in government and enterprise contexts. ### Open source with no vendor lock-in You own your data, your code, and your hosting. There's no monthly SaaS bill that scales with your content volume, and you can move between hosting providers without rewriting anything. ## Key pain points Here's the uncomfortable truth about Drupal: it's powerful, but it demands a level of investment that most teams underestimate. The learning curve is brutal. We're not talking about a weekend of tutorials; we're talking about months before a developer is truly productive. Drupal 8 and beyond adopted Symfony patterns, which is great for architecture but means you now need a PHP developer who also understands dependency injection, service containers, and YAML configuration files that seem to multiply overnight. Finding and retaining Drupal talent is genuinely difficult, and the developer survey data confirms it: fewer than 10% of the community is under 30, and almost nobody is joining fresh. The upgrade story has been a recurring nightmare. The jump from Drupal 7 to 8 was essentially a full rebuild, and the ongoing churn from PHP and Symfony upstream changes means your team spends a meaningful chunk of time just keeping the lights on. Module compatibility breaks, themes need reworking, and the update process still isn't fully automated. If you're on a lean team, that maintenance burden is going to eat into your feature development time. And then there's the content editor experience. Drupal was built by engineers for engineers, and it shows. The admin interface is functional but far from intuitive, and content teams coming from friendlier platforms consistently struggle with it. You can improve things with contributed modules and custom configuration, but that's more time and money. If you don't have the budget for a dedicated Drupal team or a long-term agency partnership, you're going to have a bad time. ### Punishing learning curve Getting productive in Drupal takes months, not days. The combination of Symfony patterns, YAML configuration, and Drupal-specific conventions means onboarding new developers is slow and expensive. ### Shrinking talent pool The developer community is aging out. Fewer than 10% of Drupal developers are under 30, and new developers aren't joining at a rate that replaces those leaving. Finding affordable Drupal expertise is a real challenge. ### Painful upgrade cycles Between PHP version bumps, Symfony updates, and Drupal core changes, your team will spend significant time on maintenance that has nothing to do with shipping features. The Drupal 7 to 8 migration was so brutal they delayed end-of-life for years. ### Poor content editor experience The admin interface was designed by developers, and it shows. Content teams coming from WordPress, Sanity, or any modern CMS will find the editing experience clunky and unintuitive without significant customization. ### Resource-hungry infrastructure Drupal is not light. It demands proper server resources, caching layers, and database optimization to perform well. Cheap shared hosting won't cut it, and infrastructure costs add up quickly. ### High total cost of ownership It's open source, but don't let that fool you. Between specialized developers, hosting requirements, ongoing maintenance, and the sheer time investment to configure everything, Drupal projects consistently cost more than teams expect. ## Frequently asked questions ### What makes migrating from KeystoneJS difficult? KeystoneJS stores data through Prisma, so the database layer is well-structured and easy to export. The harder part is replacing everything Keystone doesn't give you. Most Keystone projects have custom-built preview systems, publishing workflows, and access control logic that are tightly coupled to the Node.js backend. Rebuilding those features in a new CMS takes planning. We typically budget 4 to 8 weeks for a Keystone migration depending on how much custom infrastructure the team has built around it. ### Why do teams move away from KeystoneJS? Deployment complexity is the number one reason. Teams love Keystone during local development, then hit a wall getting it reliably into production. The Docker images can balloon past a gigabyte, the docs don't cover production hosting well, and there's no managed hosting option. The small community compounds this problem. When you hit an edge case, there are fewer people who've solved it before. Content editors also struggle with the admin UI, which lacks visual editing, live preview, and built-in publishing workflows that competing platforms ship by default. ### How do we extract our content from KeystoneJS? Since Keystone uses Prisma ORM, your content lives in standard PostgreSQL, MySQL, or SQLite tables with clean schemas. You can export directly from the database using SQL dumps or Prisma's query API. The content model is defined in your TypeScript codebase, so mapping fields to a new CMS is straightforward. We write automated scripts that handle the data transformation, including resolving relationships between lists and migrating file references. For a project with 20 to 50 Keystone lists, extraction and transformation usually takes 1 to 2 weeks.