Currently knee-deep in moving a Rails 2.3 app (on MySQL) over to Phoenix with LiveView + PostgreSQL. This app has zero specs. Nada. Zilch. But it’s been quietly doing its thing for the client for the last 15 years without many hiccups. So, I’m basically doing surgery on a patient that’s been healthy for a decade and a half. The reason for the operation is that it’s getting harder to keep the old JS libraries like Prototype limping along, and the customer recently took a hit when they were forced to migrate from MySQL 5.7 to MySQL 8. That alone required a big lift to move Rails 2.3 over to Rails 2.3 LTS, and they don’t want to go through another “fire drill” like that ever again.

Didn’t want to just throw the entire codebase into Claude or ChatGPT and pray, so I’ve been breaking the migration down into chunks:

1. Dumped the MySQL DB schema → fed it to AI to get a Postgres version, plus suggestions for cleaner field types and future-proofing.
2. Logged all the field type changes, then used draw.io to map out how the tables actually connect so I could decide which models to tackle first.
3. Spun up a barebones Phoenix + LiveView app and scaffolded those models in priority order.
4. Right now: pulling in the old business logic one model at a time, while getting AI to crank out tests for each bit as I go. This part is equal parts archaeology and translation work. Finding ancient Rails patterns and figuring out their shiny new Elixir equivalents.
5. Next up will be staging for the client’s management to kick the tires.
6. Then a tiny rollout to 1–2 locations for a couple months of feedback.
7. Expand to ~25 locations for another few months of tweaks.
8. Finally, the big switch for all 100+ locations.

One extra wrinkle: most of the production data from MySQL ultimately ends up in ClickHouse for warehousing. As I launch these new locations, I plan on setting up triggers in Postgres so it will automatically dump the exact same data format for the warehouse into a temp table that I sync daily. This way, the downstream analytics won’t even notice the migration happened. Once the rollout is solid, the next big mountain will be refining and transforming that warehouse data.

I was a skeptic for a long time but as it usually happens in life, I was forced to use it to appreciate it. I grumbled about it, of course, like every self-respecting aging techie, but came to appreciate it a lot.

Best feature is being able to describe one resource’s data model once and then reuse that for JSON API, GraphQL, storage backends like PostgreSQL / sqlite3, and others. Also before_action / after_action, notifiers, PubSub… The authors did an amazing job.

Feel free to ask about how to do this and that. I am not an expert by any stretch but the parts that I learned I know pretty well. Busy as all hell too but I stop by in the forum 1-2 times a day.

While you are at it, I strongly recommend skipping the more raw Ecto stuff and just use Ash. You declaratively describe stuff and it can even generate the migrations for you, though it can do much, much more than that. It’s a joy to use and allows you to compartmentalize stuff a la Phoenix contexts but IMO better.