A mature Rails application holds more than code. It holds the rules behind invoices, subscriptions, permissions and everyday customer work. Modernization should make those workflows easier to maintain while giving the team room to keep delivering.
Start with the workflows that matter
Before changing dependencies, list the paths the business cannot afford to break. For a SaaS product, that might mean signing in, switching between accounts, creating an order and collecting a payment. Record expected behavior and add focused checks where coverage is missing.
This gives the upgrade a concrete target: the important workflows still work, and the application becomes easier to change.
Make the plan small enough to review
Separate runtime compatibility, framework upgrades and feature changes into manageable steps. Read the upgrade notes for each step and inspect configuration changes rather than accepting them blindly. Keep a short record of why each dependency or setting changed.
Choose a slice with clear boundaries. An isolated reporting feature is easier to assess than a change that touches billing, authentication and deployment at the same time.
Prepare the release before changing production
Write down how you will deploy, what you will observe and how you will recover if the release fails. Database changes deserve their own review: restoring older application code may not undo a migration or restore altered data.
After release, check the workflows you identified at the start. Look at failed jobs, application errors and customer-facing behavior alongside the test results.
Keep modernization part of delivery
Give recurring maintenance a place in the roadmap. A small, understood change is easier to budget and review than a large upgrade postponed until it becomes urgent. At MIC Labs, our preferred starting point is a defined maintenance slice with an observable outcome.