Hacker News Reader

Comment by gruseom | Hacker News Reader

It isn't clear from the article whether the new system is in production and the old system has been thrown away. Those are the two most important questions.

If the company is maintaining the old system to support existing users, that's a bad sign for the rewrite. If there is a separate team for the old system, that's a really bad sign for the rewrite (not to mention for the company).

Doing this is harder than it sounds. Technical success may be a necessary condition but it isn't a sufficient one.

View on HN

The old system has been entirely decommissioned, and the team works entirely on the new system now.

How long was the transition period? A single day? What size userbase was migrated (if you can say)?

Also, thanks for writing this up - lots of good writing as usual. Having gone through a rewrite recently, and being asked to consult on another, you've identified a lot of good issues for me to revisit.

This is the part of a rewrite that scares the crap out of me. When you have thousands of users across hundreds of big clients, with millions of existing records and a decade of history, making a big switch in one go seems impossible.

Since this was a rewrite of a system that just consumed the output of the CMS, the migration was not awful. One day, we just started exporting the new data format and using the new system to create apps. Users continued to use the same CMS to build their applications -- the CMS was the target of many improvements, but didn't get replaced wholesale. Thus the rollout of the new system wasn't really impacted by the number of users of the CMS. Though the Dojo/PhoneGap system in reality exists pretty independently from the CMS, you might think of it as the presentation layer of the CMS, so this rewrite really targeted a (significant) piece of a larger system.

nice - sounds like just about the best case scenario for a rewrite, excepting a total scrap and start over of the whole company :)

Reply on news.ycombinator.com