When replacing a legacy system, gradually take over its workload beginning very early in the project. I was talking with a friend recently about a grocery chain that was planning to switch from its sophisticated home-grown software to a package. The plan was to reimplement the current functionality in the package and then cut over one Sunday night. My instant response was, "That trick never works."
Every once in a while a big deployment works. You spend months not adding any new functionality just getting ready for D-Day. People work long hours and weekends. If the bet pays off and the new system runs well enough, everyone is too exhausted to return to productive development for weeks or months. And if the bet doesn't pay off and the new system has to be pulled, the costs are even higher. Big deployments have a high risk and high human and economic costs.
What's the alternative? Find a little piece of functionality or a limited data set you can handle right away. Deploy it. You'll have to find a way to run both programs in parallel, splitting and merging files or training some users to use both programs. This scaffolding, technical or social, is the price you pay for insurance.
I used to believe in incremental deployment in my head, not my gut. A job helping to migrate nine thousand contracts to a new system changed my mind. After a couple of months we could handle 80% of the contracts, but because of data quality problems we couldn't match the answers for the other 20%. We spent six months trying to get the rest of the contracts working, including duplicating the errors in the old system. (You wouldn't believe what they did to round floating-point numbers!) Then our manager changed priorities and asked us to convert a different set of contracts. At the end of the year we hadn't gotten any of the contracts deployed in the new system and I lost a bonus equal to the cost of a new house. Now I really, really believe in incremental deployment.