Sunsetting Mongock: Flamingock is its successor

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")<br>public class _0001__AddPaymentMethodColumn {

@Apply<br>public void execute(MongoDatabase db) {<br>db.getCollection("orders")<br>.updateMany(new Document(),<br>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...