You have a history If you have a lot of data and/or users - or a website that has evolved a lot since it’s original inception - that’s always a challenge for a number of reasons. Firstly, large migrations take time, prohibit using certain technologies, often contain more instances of “bad” data that may not be acceptable by the new system, etc. Data, and especially configuration, also has to often be translated between systems and if that data is rooted in Drupal 7 (or earlier) data models, then most certainly you’ll want to use updated field types and definitions and architectural approaches to take the most advantage of Drupal 8. It should be noted that there are better Drupal migration tools in Drupal 8 that come right out of the box in Core, but in general it doesn’t take much to trip them up. For example, the migration infrastructure works on the concept of migrating “configuration” and then “content”, but “configuration” can consist of a lot of customization provided by contributed or custom modules that simply don’t exist in Drupal 8, or are else handled very differently. At Ashday, we lean 9 times out of 10 on writing a custom migration script that does exactly what we want. This means being steeped in Drupal database structure and underlying approach though and may not suit everyone.

Contributed modules have changed Drupal 8 has considerably less stable contrib modules than Drupal 7. Why? Well, for one - Drupal 8 does a lot more out of the box. Views are included. More content concepts are entities. The block system is much more powerful. This makes for a tricky migration though because if your site-to-be-migrated is built on heavy custom programming or a host of contrib modules, you have to translate that functionality - and the underlying data - to the newer way of doing things. That likely involves redoing a considerable bit of the setup because it’s unlikely too much of it will translate cleanly. It’s all a positive mark for Drupal because Drupal 8 contrib modules tend to be much more modular in design and more consistent, but the system isn’t going to magically be able to interpret how to translate your previous site’s setup into the new one, even if you can still accomplish most of it with site building tools. All of this means that it's better to focus more of your efforts on learning how Drupal 8 wants to do things, and then secondarily figure out how best to implement your intentions.