Led a couple of these. Advice:

1) Do it incrementally. If you don't, it will fail. You can't block feature releases for a whole organization for years, but if you don't block feature releases you will forever fall behind head.

2) Design the v2 you want to have, but don't get too attached to the design. It will change as you uncover engineering realities and as business direction evolves. Be flexible and adapt as you go along.

3) It helps garner exec support if you can catalog product ideas that they've wanted to do but been prevented from by the current architecture, and address them with the new architecture. Rewrites that address new business goals and strategies have a lot more staying power than rewrites for the hell of it, or ones justified by "the code will be much cleaner".

4) If V1 doesn't already have clear APIs and subsystem boundaries, it's usually worth doing pre-work to put them in place. These take the form of behavior-neutral refactorings whose only purpose is to trim & rationalize dependencies - you're changing how the system looks to outside clients, but not how it works.

5) Make sure you have a comprehensive regression test suite. This is part of why the last point is so important.

6) The new APIs are the most important part. Get them working first, in order of which APIs are most frequently depended on by new code, even if you have to implement them on top of old code or use hacks to connect them up to the old system. And then get the rest of the org using them. This will help keep you from falling the rest of the org in development, and build momentum on the new system.

7) Separate behavior-neutral changes that change how the code works internally from behavior-adding changes that change what the code does. The former should give exactly the same results as the v1 system, pass all the existing regression test suite, and have exactly the same functionality except perhaps a latency penalty for shimming & data conversion. The latter handle any of the new functionality that are the business goals of v2, which hopefully you established in #3.

8) The project will be a lot more sustainable if you can deliver some of the business goals from #3 before your conversion is complete.

9) Have a latency budget for how much slower the new system can be than the old one. It will be slower than the old one, and don't try to message otherwise. This is why you try to get it used for new functionality (#6) first; these often have fewer users, so inefficiency causes less of a penalty for overall experience.

10) Also, expect bugs and lots of them. This is the other reason to get it used for new code (#6) before migrating over critical core functionality; it lets you smooth out the kinks before you cause career- or business-ending failures.

11) If v2 has a different data backend from v1, you will need a dual-write layer, because there's going to be a period of time when both backends are live. Consistency-check both backends against each other to catch bugs before trying to switch fully over to v2.

12) Test your migration scripts, and treat them with the same care you treat production code. A one-character error in the migration script that moved GMail over to BigTable ended up deleting 10% of GMail accounts and necessitating a tape-backup restore that knocked out people's GMail for a week. If Google can screw it up, you can too.

13) When it comes to migrating over the long-tail of functionality, enlist the rest of the org's help, have a bunch of whole-company Fixits, and put lots of people on it. By the time you do this, everything in v2 should be stable, people should know the dragons in the new system, and migration should be pretty straightforward. But this work tends to burn engineers out, because it's boring and has virtually no real benefit other than being able to get rid of V1.

14) Expect this project to suck, to take about 5x more man-hours than you expect, and to face cancellation at numerous intervals. You should not be embarking on this unless business leaders are sure that you really need to, and you have their complete buy-in.

Good luck.