There are many, many ways to migrate into SharePoint: from an earlier version of SharePoint, from a platform other than SharePoint, in-place upgrade, and into a new farm. And as many ways as there are to migrate, there are even more ways to botch it up.
Choosing the wrong migration strategy
There are three primary methods of migrating to SharePoint: Database Attach, scripted moves, and manual transfer. Each has its pluses and minuses.
Database Attach is the simplest: Detach the old SharePoint database from its legacy SQL Server instance, then attach it to the SQL Server instance in the new farm into which the content will be migrated.
Scripted moves are the most versatile and effective: Move the legacy system into the new farm in pieces, and have the moves written up as batch jobs.
Manual transfer is the slowest but also ensures that someone is monitoring all the content that comes across: Site owners rebuild their sites in the new farm and copy over necessary content manually.
A state government cabinet in the Midwest undertook a migration with adequate funds for the new farm infrastructure, but did not have much set aside to finance the actual migration. The department decided on the Database Attach method because it would be the fastest, cheapest route: Transfer all the content as-is, then restructure it in the new farm as time allowed. This turned out to be a very bad decision.
By skipping the planning of a new, broader metadata taxonomy up front, the post-migration system was weighed down with terabytes of clutter, and the errors of the old system -- including dozens of ungainly, disorganized folder hierarchies -- were copied into the new system. There wasn't sufficient staff to maintain the old and the new system in parallel while the mess was sorted out, so several thousand users were infuriated at having to go back and deal with metadata usage conflicts on the fly, essentially doing the work that was supposed to be skipped. They may as well have migrated manually.
A second issue was that, after the new SharePoint system went live, the infrastructure of the original farm was repurposed. The rationale was that because the legacy system lacked sufficient support, there was no point in tying up the servers. This amounted to another bad decision.
No training budget
A human resources company with offices around the globe migrated into SharePoint from a non-Microsoft CMS, which had accumulated more than a decade of compliance-sensitive content. Considerable budget was set aside for the SharePoint farms (several, in different countries) -- but no money was set aside for training.
A decision like that is unusual enough for an HR company, but even more baffling when one considers that the migration wasn't SharePoint-to-SharePoint. Part of that was the fault of the migration's IT champion, who sold the project with assurances that SharePoint is so easy to use that users pick it up in no time.
User hostility to the new platform was high and climbing from the outset. Site owners were uncoordinated in their efforts to work together to implement common standards of usage; users, unfamiliar with the best practices, began to create sprawl, which the site owners had trouble containing. And the exploitation of SharePoint's most desired new features was hit-and-miss at best.
No measurable goals
In that same HR company migration, an executive not directly involved with the project set an arbitrary go-live date, and only after three months of the migration process, it became obvious that the sheer volume of content to be migrated could not be in the given time frame. Retroactively, tests were undertaken to establish baseline transfer rates and identify bottlenecks. But all of these precautions should have been taken beforehand. Months of schedule had already been burned up unnecessarily.
Time is money; money is time
The safest, most versatile migration method is scripted moves: batch jobs that bring sites and content over from the legacy system to the new farm, in controlled bursts. This takes a while but also affords a substantial control.
The problem with such a migration is that when done in-house, it takes a long time and ties up IT resources. On the other hand, many companies (Knowledge Lake, AvePoint) specialize in this sort of migration, and can help plan it well and execute it much faster than house staff can. The tradeoff, of course, is dollars.
Faced with this kind of choice, a Louisville manufacturing company opted for a scripted-move migration, with the in-house staff handling the work: The company required attention to detail and the new environment contained many structural changes.
But the project stretched out almost geometrically and the schedule slipped again and again, because in-house personnel -- though capable of dealing with the glitches during the scripted transfers -- had never dealt with them before. So while problems were getting solved, things were piling up because it was taking too long to solve them. And this was in the test environment: The scripting issues and transfer problems were so many that no actual migration into the new production environment was accomplished.
After more than two months of this, a third-party company was brought in to help. The third party knocked out the entire migration in less than six months.
If there's a moral to these tales, it's one that is common across the board with SharePoint: planning ahead always pays off.