.NET › API Versioning

How do you handle database schema changes that need to support multiple concurrently deployed API versions during a migration window?

Advanced

Answer

Common patterns include: additive-only migrations (add new columns/tables without removing old ones until all versions are retired), expand-contract migrations (first 'expand' the schema to support both old and new shapes, deploy code that writes to both, then 'contract' by removing the old shape only after all consumers migrate), and maintaining a translation/mapping layer in application code so different API version handlers read/write the same underlying schema through different DTOs.

-- Expand-contract pattern:
-- Step 1 (expand): ALTER TABLE Products ADD COLUMN currency_code VARCHAR(3);
-- Step 2: deploy code where v2 writes currency_code, v1 continues ignoring it
-- Step 3 (contract, after v1 retirement): safely remove any v1-only compatibility columns

Real-world example A team migrating a pricing field from a single decimal to a currency-aware structure uses expand-contract: adding new columns first, running both API versions against the same expanded schema, then cleaning up only after v1 is fully retired.

Common follow-ups: What's the risk of skipping the expand-contract pattern and doing a direct schema change?;How long should the 'expand' phase typically last?

Entity Framework Core & Data Access;CI/CD Publishing & Deployment