A legacy codebase has table and variable names like cust_tbl, proc_flg, and acct_stat_cd that no longer match how the business actually talks about the domain today. Is renaming these to match current domain vocabulary worth doing, and how would you approach it without a risky big-bang rewrite?

## Code renames and schema renames are different problems The decision to rename legacy artifacts like `cust_tbl` or `proc_flg` to match current domain vocabulary is fundamentally a cost-benefit judgment, not an automatic 'always do it' rule, and the mechanism for doing it safely is different depending on which layer — code or schema — you're touching. - **In application code** (class names, variable names, method names), renaming is comparatively cheap: modern IDEs perform safe, compiler-verified renames across an entire codebase in seconds, and the risk is low because the change is purely textual with no runtime behavior difference. - **In a database schema, however**, a column or table rename can break every application, report, ETL job, and ad hoc query that references the old name directly, some of which the renaming team may not even know exist — so schema renames need to be treated as a distinct, higher-risk migration, not folded into the same effort as a code cleanup. ## Why the gap opens in the first place The reason this problem exists at all is that legacy names are usually artifacts of old constraints that no longer apply: - decades-old naming conventions that capped identifiers at 8 or 30 characters, forcing abbreviations like `proc_flg` for 'processing flag' or `acct_stat_cd` for 'account status code'; - or names chosen by an early team before the current domain vocabulary had even stabilized. Over years, the business's actual language moves on (analysts stop saying 'account status code' and start saying 'membership tier', say), but the schema is frozen in amber because changing it is expensive and risky, so a widening gap opens between what the business calls something and what the database calls it — exactly the ubiquitous-language drift problem, except calcified in a place (a production schema with years of dependents) where fixing it is much more expensive than fixing a class name. ## The trade-off The trade-off is real engineering time and migration risk versus an ongoing, compounding **translation tax**. Every engineer who touches this code pays a small toll indefinitely: they have to remember that `proc_flg` means 'processing flag' (not, say, 'processed' or 'procurement'), that acct_stat_cd's cryptic values map to specific business states, and new hires take longer to become productive because the schema actively obscures the domain rather than expressing it. That toll, paid by every engineer for years, can easily exceed the one-time cost of a careful migration — but only if the migration is actually careful; a rushed, big-bang rename that breaks a downstream reporting job during a busy period can cost far more in incident response and trust than the years of minor confusion it was meant to fix. ## The safe approach The safe approach borrows from the **strangler fig pattern** used for legacy modernization generally: introduce translation at a layer boundary rather than renaming the thing everyone already depends on. Concretely, an application-level repository or mapping class can expose clean, domain-accurate methods and types — `findCustomerAccountStatus()` returning a `MembershipTier` enum — while internally still querying `cust_tbl.acct_stat_cd`, so every new piece of application code gets to work against clear, ubiquitous-language-aligned names immediately, with zero schema risk. If and when the schema itself is worth migrating (because, say, direct SQL access by other teams or BI tools makes the cryptic names a persistent problem beyond the application layer), that's done as its own additive, reversible migration: 1. add a new column with the clear name, 2. backfill it from the old column, 3. dual-write to both during a transition window, 4. migrate all known consumers over, 5. verify, 6. and only then drop the old column — never an in-place rename that has no rollback path if an unknown consumer breaks. ## Failure modes on both sides Failure modes show up on both sides of this decision. - **Doing nothing indefinitely** means the confusion tax keeps compounding — bugs from misreading acct_stat_cd's encoded values, onboarding friction, and a codebase that increasingly requires tribal knowledge to navigate, which is a real, if slow-burning, cost. - **Doing it recklessly** — an in-place `ALTER TABLE RENAME COLUMN` run against a production schema without first finding every consumer — is the more dramatic failure: an unknown nightly ETL job or a BI dashboard's raw SQL query breaks silently until someone notices stale numbers days later, which is a strong argument for the application-layer-first, additive-migration-later approach. A concrete real-world pattern this maps to is any large, long-lived system with a mainframe-era or early-2000s schema underneath a modern application layer (common in banking and insurance systems) — teams there routinely build a clean domain layer in code on top of a schema they can't easily touch, precisely because the schema-migration risk and the code-cleanup benefit are decoupled problems best solved on different timelines.