Comparing v1 → v2
+20 additions
-32 deletions
v1 → v2
-# Rails 3 to Rails 7 Upgrade Plan
+# Rails 3 to Rails 7 Upgrade Plan (Revised)
## Background
Client has a Rails 3.2.22 application running in production since 2013. The app serves approximately 40 users in a regional insurance office. It runs on a single Heroku dyno. Nobody has touched it since Gary left in 2017.
-Gary did not leave documentation.
+Gary did not leave documentation. Gary has been located. Gary does not remember the app.
## Current State
- Ruby 1.9.3 (EOL: February 2015)
- Rails 3.2.22 (EOL: June 2016)
- 847 gems in Gemfile.lock, 211 of which no longer exist on RubyGems
- Asset pipeline uses Sprockets with CoffeeScript and Sass
- Tests: 3. One passes. One is pending. One tests a feature that was removed in 2015.
- Deployment: `git push heroku master` with no CI
- Database: PostgreSQL 9.2 (EOL: November 2017)
-- The app stores passwords in MD5. Gary thought this was fine.
+- The app stores passwords in MD5. This is not fine.
+- A nightly job sends data to a company in Ohio that nobody knew about
-## Proposed Approach
+## Decisions Made
-### Option A: Incremental Upgrade
+1. **Rewrite, not upgrade.** The incremental path is not feasible. See [post-mortem](post-mortem.md) for why.
+2. **Keep the MysteryWorker.** The company in Ohio depends on it. We will rebuild the integration properly in the new app.
+3. **Contact Ohio.** They have documentation for the data format. Gary did not. Ohio is more organized than Gary.
+4. **MD5 passwords.** Force password reset for all users on launch day. No migration path for MD5. We told the client. The client said "Gary said MD5 was fine." We said Gary was wrong. The client seemed unsurprised.
-Upgrade one major version at a time: 3→4→5→6→7. Each step requires updating gems, fixing deprecations, running tests (the one that passes), and deploying.
+## Revised Timeline
-**Estimated time:** 6-8 weeks
-**Risk:** High. Many gems have no upgrade path. Some gem authors have moved on to goat farming.
+| Sprint | Goal | Duration |
+|--------|------|----------|
+| 1 | Discovery and environment setup (complete) | 3 weeks |
+| 2 | New Rails 7 app, core models, authentication | 2 weeks |
+| 3 | UI rebuild, data migration scripts | 2 weeks |
+| 4 | Ohio integration rebuild, MysteryWorker replacement | 2 weeks |
+| 5 | Testing, security audit, deployment | 1 week |
+| **Total** | | **10 weeks** |
-### Option B: Rewrite
+Original estimate was 4-6 weeks. Revised estimate is 10 weeks. This is because of Ohio.
-Start fresh with Rails 7. Replicate existing functionality. Migrate the database.
+See also: [gem audit](gem-audit.md) for dependency analysis.
-**Estimated time:** 4-6 weeks
-**Risk:** Medium. We know what the app does. Mostly. The parts we don't understand are probably important.
-
-### Option C: Leave It Alone
-
-The app works. Nobody is complaining except the security auditors. The security auditors are always complaining.
-
-**Estimated time:** 0 weeks
-**Risk:** The security auditors will not stop. They will never stop.
-
-## Recommendation
-
-Option B (Rewrite). The codebase has too much technical debt for an incremental approach. The CoffeeScript alone would take two weeks to untangle, and nobody on the team knows CoffeeScript. We hired someone who said they knew CoffeeScript but it turned out they were thinking of TypeScript.
-
-## Open Questions
-
-- What does the `MysteryWorker` background job do? It runs every night at 3 AM and writes to a table called `legacy_sync`. The table has 3.2 million rows. Nobody knows what it syncs or where it syncs to.
-- Is the SMTP server at 10.0.0.47 still running? The app sends emails to it. We cannot find this server. The IP doesn't respond to pings. The emails appear to be delivered anyway.
-- Why does the User model have a `is_gary` boolean column?
-
-See also: [gem audit](gem-audit.md) for the full dependency analysis.
-