So I have migrated two systems completely, and worked in a bunch otherwise. The overall way we did system migrations was to take sections of the system and carve them out and then implement it completely. For example, product catalog was one, and for a short time the UniVerse and our system were running concurrent and over a couple of months we just turned off the old product catalog. This just went on and on through the entire system. IMO this is the only way to migrate really large projects because there wouldn't be stomach enough from the business to have a big bang project, and the chance of failure skyrockets when you try to accomplish too much at once.
The largest system we migrated was using somewhere around 25 very large Unix servers running UniVerse, handling millions of transactions per day and I think somewhere around 10 years of history. It was very large by UniVerse standards IMO. We moved that one to Postgres for the primary database and just partitioned the data properly, as well as separated transactional systems from data warehouse usage which was very large for that client. UniVerse was trying to be everything to everyone. The two biggest parts of their UniVerse install was the data around invoices and products, which also had the most code written too. And that is where all the Pick guys/gals said only Pick can do this properly, RDBMS can't handle invoice line items in a performant way etc. So they wrote really tight query performance requirements for us cause they wanted it to fail. They really felt it would just fail. My teams experience was all around large data and distributed systems so we had no issues with this overall, not that it was easy but we just kept to solid basic fundamentals and it all worked out well.
The key things we were able to really solve for them was the concurrency and reliability issues. Like you know these systems struggle with concurrency, locking and corruption. Corruption is a factor of code quality too, but Pick made it easy to corrupt data cause the type system sucks too.
The largest project, described above took us a year to get implemented, and roughly like 6 months between planning and testing (so ~18 months total). It was not a small undertaking, and our fees alone were pretty significant. To be fair though, our fees were peanuts compared to the amount of money we were able to save them, so we never had any pushback on our fees and we were not inexpensive. We probably could've done it faster to be honest, because 80% of the system was for known design patterns, e.g. product catalog, invoicing, customers etc. But a lot of time was spent dealing with the pushback from their Pick engineers kicking and fighting the whole time and not showing us pieces of the system trying to sabotage the project. Sadly a few of their Pick people just imploded and got fired for this behavior, but I will say it was mostly a small group of them really opposed. A good number of people wanted to learn new skills and the company was happy to train their people, and we worked with them to hire a training group that specialized in training databases etc. In the end, there was still a pretty significant layoff of people who just couldn't make the transition, which always sucks to see.
