Checklist: Shipping calendar-year changes safely under stress

Calendar-year changes are predictable and still manage to surprise.

New pricing, new tax rules, new reporting formats—these all tend to land when teams are tired, support is busy, and there is little appetite for risk.

This checklist is how we make those changes boring instead of dramatic.

Context

Use this checklist when:

• changing prices or billing logic around year-end
• updating tax or compliance-related behavior tied to dates
• altering how we generate or expose year-based reports

It assumes:

• you already have a basic design
• you know which services and teams are involved

Checklist

• Have we isolated the change?

  • use feature flags or config toggles where possible
  • avoid bundling unrelated features into the same deploy

• Do we have realistic test data for new-year scenarios?

  • include boundary dates (Dec 31, Jan 1)
  • cover different time zones and locales where relevant

• Have we planned the rollout time with support?

  • avoid shipping at the exact moment users expect reports or renewals
  • ensure support knows when changes go live and what to expect

• Is there a rollback path that doesn’t corrupt data?

  • rolling back code is easy; rolling back partially-applied data is not
  • document what rollback means for in-flight records

• Are monitoring and alerts scoped to the change?

  • add temporary dashboards or views that highlight the new behavior
  • verify alerts exist for obvious failure modes (e.g., sudden drops in invoices or spikes in rejections)

• Have we agreed on who is on point during and after the change?

  • on-call knows when to watch
  • product and finance stakeholders know how to reach the incident channel

Notes

We learned that year-end is not the time to prove how much risk we can take.

A few patterns that helped:

• ship enabling changes earlier, behind flags, so the year-end switch is mostly configuration
• do a "dry run" in staging with realistic dates and data
• write down the first few checks someone should do after the change (dashboards, sample records)

Takeaways

• Year-end changes are predictable; treating them as surprises is a choice.
• Flags, realistic test data, and scoped monitoring reduce the chance of last-minute incidents.
• Coordination with support and stakeholders matters as much as the code change.

Further reading

• Estimates as ranges
• Ship the runbook with the change