In this tutorial on SitePoint.com author Daniel Sipos introduces you to the concepts behind the Migrate module in Drupal 8 and how it can be used to move content over from other sources.

Migrate is one of the most established modules in the Drupal ecosystem. So much so that with Drupal 8, a decision has been made to get some of its functionality ported and added to Drupal core. An important reason was that the traditional upgrade between major releases was replaced with a migration of Drupal 6 or 7 content and configuration to Drupal 8.

[...] In this article we are going to look at how migration works in Drupal 8 by migrating some content into node entities. For simplicity, the data we play with resides in tables in the same database as our Drupal installation.

He starts but outlining the "migration theory" and parts of the process to get the data in to your Drupal 8 instance: the source, the process and the destination. He uses a movie content example to show the setup needed to create the tables and define the configuration for the relationship to genres. He then shows how to make the migration configuration, defining the three parts and how to define the related migration classes. He ends the post with the drush command to execute the migration, get the current migration status and roll them back if something unexpected happens.

In a new post to his blog today Alan Skorkin compares two ways of thinking about developing software - either as a destination or as a journey.

There are two fundamental ways of looking at software development. One is all about the final product and the direct benefits you can get from it. The other is all about the lessons you learn from the process of building the software. I call them software as a destination and software as a journey. Historically speaking and even into the present day, the majority of companies that build any kind of software are 'software as a destination' companies.

He notes that, despite the company's stance on the software that's developed, most developers are more in the "journey" category and want to enjoy what they do and to evolve in their skills as they move through their career. Therein lies some of the problems with the software development industry - companies want the result, developers want what's best for the code and want to see it turn out as well as hoped.

I am not sure if there is any irony to be found in software, but if you direct all your focus towards your goal without paying due attention to the nitty gritty of what you're doing every day, you're likely to not get any useable software out of it. As long as you have a reasonable idea of where you want to end up, you just need to get the details right and the bigger picture will tend to sort itself out. On the other hand, you can have the clearest possible goal in mind, but if you let the details slide, bad things will almost certainly happen.