How to Discuss Database Migrations in a Meeting

Database migrations are one of the riskiest categories of change in software engineering, and explaining them clearly to a room of engineers, product managers, and sometimes executives requires precise English. Vague language like “we’re changing the database a bit” undersells the risk, while overly technical jargon loses non-engineering stakeholders. This guide gives you vocabulary and phrases for discussing database migrations clearly in a meeting.

Key Vocabulary

Schema change — a modification to the structure of a database, such as adding a column, changing a data type, or creating a new table. “This is a schema change, not just a data change — we’re adding a new required column to the orders table.”

Backward-compatible migration — a migration that doesn’t break existing code or clients that haven’t been updated yet. “We designed this as a backward-compatible migration — old application code will keep working even before it’s updated to use the new column.”

Zero-downtime migration — a migration performed without taking the application offline, typically achieved through multi-step, incremental changes. “We’re doing this as a zero-downtime migration in three phases, rather than one big change that would require a maintenance window.”

Backfill — the process of populating a new or changed column with data for existing rows, often run as a background job. “After adding the column, we’ll run a backfill job overnight to populate historical rows before making the column required.”

Rollback plan — the documented steps to reverse a migration if something goes wrong, including how far back the change can be undone. “Our rollback plan lets us revert the schema change within the first hour, but not after the backfill job starts deleting the old column.”

Maintenance window — a scheduled period, ideally low-traffic, during which a riskier change is performed with reduced impact if something breaks. “We’ve scheduled the maintenance window for 2 a.m. on Saturday, when traffic is at its lowest.”

Data integrity — the correctness and consistency of data, a primary concern when running migrations that touch existing records. “Our biggest concern with this migration is data integrity — we need every existing row correctly converted, not just new ones.”

Locking (table lock) — a database mechanism that can block reads or writes during certain schema operations, a common cause of migration-related outages. “This type of column addition requires a table lock in our database engine, so we need to run it during low traffic to avoid noticeable slowdowns.”

Explaining the Plan to the Team

• “We’re splitting this into three deploys: add the nullable column, backfill existing rows, then make it required. Each step is independently safe to roll back.”
• “The migration itself should take under two minutes, but the backfill job will run in the background for a few hours.”
• “We chose an online schema change tool specifically to avoid a table lock, since this table gets constant traffic.”

Answering Questions From Stakeholders

• “What happens if something goes wrong mid-migration?” — “We have a rollback plan for the first hour. After the backfill starts, reverting gets more complex, so we’ll pause and reassess before that step.”
• “Will this cause downtime?” — “No, this is designed as a zero-downtime migration — the application keeps running throughout.”
• “How confident are we in the timeline?” — “We tested this exact migration path against a copy of production data, so the estimate should hold, but we’ve built in buffer for the backfill.”

Raising Concerns About Risk

• “I want to flag that this migration touches our largest table — I’d like a second engineer to review the rollback plan before we proceed.”
• “Given the size of the backfill, I’d rather split it into smaller batches than run it as one long job that could time out.”
• “I’m not comfortable running this without a maintenance window, even if it’s technically zero-downtime — the blast radius if something goes wrong is too large.”

Professional Tips

1. Distinguish schema changes from data changes clearly. Stakeholders often conflate the two, but they carry very different risk profiles.
2. Always state the rollback plan, even briefly. “We can revert within an hour” reassures a room far more than a purely optimistic description of the happy path.
3. Quantify risk in terms of blast radius and reversibility, not just probability. “Low risk, but hard to undo” is a very different statement from “low risk, easily reversible.”

Practice Exercise

1. Explain to a product manager, in 3-4 sentences, the difference between a schema change and a data backfill.
2. Write a short rollback plan summary (4-5 sentences) for a migration that adds a required column to a large table.
3. Write a response to a stakeholder asking “will this cause downtime?” for a migration you’re running with an online schema change tool.