In 2018, we built Mongock because MongoDB had no official way to manage evolutionary change safely. Teams were applying schema and data changes by hand, hoping the right change reached the right environment in the right order.

We believed those changes belonged alongside the application itself: versioned with the code, reviewed in pull requests, and owned by the engineers who understood the domain.

That idea worked.

Over the last few years, thousands of developers have used Mongock in production. They proved that Change-as-Code wasn't just a database migration technique — it was a better ownership model for evolving stateful systems.

Today we're announcing the next chapter of that journey. Mongock is entering maintenance mode and will reach end-of-life at the end of 2026. From today forward, Flamingock is where all active development happens — available now, open source, production-ready, and already able to migrate existing Mongock deployments.

This isn't a rebrand. It's the continuation of the same idea applied to a much larger problem.

Why now

Mongock solved one important part of the problem: evolving databases safely. But modern applications rarely evolve a database in isolation.

A change to a domain model often affects several systems at once — a database schema, an API contract, a Kafka event definition, an API gateway policy, a content model, a configuration store. The application team owns the business change and understands the full dependency chain, but the execution is fragmented across tools and teams, with no shared record of how the overall evolution unfolded.

That's where the incidents live now: the change that reached eleven of twelve services, the schema update applied to consumers before producers, the content model promoted while one service still read the old shape. None of these are database problems. They're system evolution problems.

Over the last year, we've explored that challenge publicly through our writing on execution layers, evolution governance, and Change-as-Code. The conclusion was consistent: the real problem was never database migration — it's governing change across all the systems an application depends on. We built Flamingock to solve that broader problem.

The pressure only grows as software creation accelerates. Whether changes are written by engineers, generated with AI assistance, or assembled through automated delivery workflows, every one still has to be applied safely, in the right order, with a reliable record of what happened. Generating change is getting easier; governing it is getting harder. The faster an organisation can ship, the more Change-as-Code is worth as the thing that keeps trust, traceability, and safety intact.

What Flamingock is

Flamingock takes everything that made Mongock work and generalises it.

The same principles remain:

• Changes are expressed as code.
• Changes execute in a deterministic order.
• Changes run exactly once.
• Every execution is recorded in an auditable ledger.
• Application teams own the change.

What changes is the scope. Where Mongock focused primarily on databases, Flamingock is designed to provide a common Change-as-Code model across the systems applications depend on, including databases, schema registries, message brokers, API gateways, configuration stores, and other stateful platforms.

The application team is the only group that understands the full dependency chain between those systems. That makes the application the natural place to declare how change should evolve.

We call this discipline Change-as-Code, and a clear line sits between it and Infrastructure-as-Code. Terraform and Pulumi provision infrastructure: they create the database, the cluster, the bucket, the queue. Flamingock evolves the stateful data and configuration inside those systems — schemas, records, content models, contracts, operational state. These layers complement each other rather than compete.

CI/CD deploys the application. Flamingock governs the evolution of the systems it depends on.

If you've written a Mongock change unit, the model will feel familiar — and slightly cleaner. @ChangeUnit becomes @Change, @Execution becomes @Apply, and ordering lives in the class name rather than a separate attribute.

@Change(id = "add-payment-method-column")
public class _0001__AddPaymentMethodColumn {

    @Apply
    public void execute(MongoDatabase db) {
        db.getCollection("orders")
          .updateMany(new Document(),
              set("paymentMethod", "UNSET"));
    }
}

The same idea you already know. Applied more broadly.

Mongock did exactly what it was supposed to do

It's worth being explicit: Mongock is not reaching end-of-life because it stopped working or because the project failed. Quite the opposite. It solved the problem it was created to solve and continues to do so successfully in production today.

What changed wasn't the validity of the model. What changed was our understanding of the scope of the problem. The more teams adopted Mongock, the clearer it became that database evolution was only one part of a much broader challenge: governing change across all the systems an application depends on.

Flamingock exists because the principles behind Mongock proved larger than MongoDB. If you've followed our recent series on execution layers and evolution governance, Flamingock is our implementation of those ideas — the series described the problem space, and Flamingock is the platform we're building to solve it.

What this means for you

Here's the short version:

Staying on Mongock through the end of 2026 is fine. When you're ready to move, you don't rewrite anything, and your history comes with you. The team is here to help if you get stuck.

The detail is equally straightforward. Mongock enters maintenance mode immediately and will reach end-of-life at the end of 2026. Until then, we'll continue providing critical bug fixes and security updates, while all new feature development moves to Flamingock. The Mongock repository will remain public, existing releases will stay available, and issues and discussions will remain open throughout the maintenance period. After end-of-life, the project will continue to be accessible, but it will no longer receive bug fixes, security patches, or feature enhancements.

We also know that migration announcements often create anxiety — too many of them translate into months of work for little immediate value. We've worked hard to make this one different.

Flamingock provides first-class support for teams coming from Mongock. In most cases, migration is a single dependency and a single annotation — you don't touch your existing change units at all. Flamingock treats them as immutable historical records, imports your Mongock audit history automatically, recognises which changes have already executed, and continues from there. The migration guide walks through it end to end.

You keep your history. You don't rewrite your past.

For teams that want to modernise existing change units into native Flamingock style, we've also built a migration skill for Claude that performs the conversion automatically. It's an accelerator, not a requirement.

And you won't be doing it alone. If you hit a snag, have a question, or want a second opinion on a tricky migration, open an issue or start a discussion. We'll help.

Where the journey continues

For the Open-source community

Flamingock remains open source and free to adopt, just as Mongock always was. That's where the core lives, and where it will keep evolving. Today it's JVM-native; over time, we'll expand beyond the JVM as Change-as-Code grows to match the way modern teams build software.

For Enterprises

There's also a layer beyond the open-source engine, for organisations that need broader visibility and governance. A single application's change history is valuable; a unified view across hundreds of services is more valuable still. Once an organisation can see every deliberate change across its environment, new possibilities open up: centralised auditing, governance, compliance reporting, organisational visibility, and cross-service coordination. That's the role of Flamingock Cloud and the self-hosted enterprise edition. The open-source engine stays the foundation; these capabilities build on top of it for teams operating at larger scale.

If you're already feeling the limits of a per-service view of change, we'd be happy to show you where we're heading.

Thank you

Before we close this chapter, we want to thank everyone who helped build it. The users who trusted Mongock in production. The engineers who reported bugs. The contributors who opened pull requests. The people who answered questions in discussions, reviewed designs, challenged assumptions, and shared feedback over the years.

Open-source projects are never built by a company alone. Mongock became what it is because of its community.

Everything we've written this past year was building toward this. If you want the full argument — why this layer exists, and why it belongs to the application team — the series is all there. Flamingock is where those ideas become real.

The principles haven't changed. The scope has.

Thank you for everything you've built with Mongock. We'll see you in Flamingock.

Get started with Flamingock · Read the docs · Join the discussion on GitHub