Before upgrading Rails, teams should conduct a 'preflight' — not a checklist, but a structured inspection of three key surfaces: the dependency graph (which gems rely on Rails internals, version constraints), the execution surface (environment differences across local, CI, staging, production), and the behavioral surface (callbacks, monkey patches, autoloading, initializer ordering). This pre-upgrade analysis transforms scattered surprises into predictable, diagnosable work, making effort more estimable, risk more bounded, and failures more explainable.
Table of contents
Preflight is not a checklist #What a preflight makes visible #The surfaces that shape an upgrade #What a preflight produces #Seeing patterns before they appear #Discovery, not compliance #What changes when you do this #The missing layer #Get new essays on software, systems thinking, and Rails delivered to your inbox. #Sort: