|P is for Practical|
Having been handed several different medium-sized systems and been told "Add these features, but keep it running", I've realized that substantial rewrites can occur quite easily.
I've also flat-out said "I need to rewrite this", and it's been ok, too.
The trick is that you have to be patient. Rome wasn't built in a day. You cannot do a new system from scratch and be able to keep the old schedules. Throw those out with the old system. Then, make new ones. Make them conservative! Be like Scotty - multiply all estimates by 4, then add 12. Then, double them just to be safe. You actually have a very good chance of getting away with this - if management complains, just quietly point to the old system. They should shut up really quick.
If you lose some customers, so be it. You would've lost them anyways if you released a bad product.
This also is a good chance to release incrementally. Get the top 10 customers involved in the design. They're using it, not you. Let them gain some ownership over the product. That way, they don't have much reason to complain over the design.
I guess the big things are patience and confidence. Build small things first. Remember that every system is a series of little things working together.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
In reply to Re: (OT) Rewriting, from scratch, a huge code base