Migrating from D7 to D8 with Lightning

Kevin Flanagan…
May82019
  1. create a space for the new Drupal 8 domain (d8-flanagan-rocks)
    1. make a Domain name
    2. make a directory for the base install (root will be inside of this)
    3. create a directory within this space and make a folder called "docroot" - (this is for testing the setup of Apache prior to downloading D8)
    4. create a virtual host on the server, pointing to the new domains directory + "docroot"
    5. test that the new directory is created by restarting apache and seeing if it recognizes the new space
    6. If Yes, go to that directory and remove the 'docroot' folder
  2. run composer in the root of the new space (where docroot has just been deleted from)
    1. composer self-update
    2. composer create-project Acquia/lightning-project docroot
  3. Create a Drupal 8 dependencies in the file system
    1. create a files directory within the new installation
    2. create a settings.php file by copying the default one
    3. make both the files directory and settings.php file writable
  4. create a MYSQL database that will be used for the new instance (record it)
  5. go back to a browser and run the Drupal install, which should start by default 
  6. Once install is complete and the Lighting System is set up, enable the following additional  modules
    • Migrate
    • Migrate Drupal
    • Migrate Drupal UI
  7. Enable modules in the new site that are also enabled in the old site
    • Inventory the modules from the old site.
      • The best way of doing this is to enable the following modules in the Drupal 7 (old) system:
        • module filter
        • module path list
      • Create a spreadsheet in Excel or Open Office Calc
      • Go to the modules view of the Drupal 7, and set the module filter to only show enabled modules. 
      • Copy the HTML table that is generated, and paste it into an empty spreadsheet.
      • When enabling modules in D8, BE CERTAIN to do regular backups and only enable a half dozen models at a time, keeping notes on what is getting enabled during each step.  You will inevitably get server errors as some modules are enabled, and being able to back up a step is crucial.
  8. important: Increase the PHP Maximum Memory allocation to 640M on your server. this is particularly essential if you have significant modules enabled for the migration. If during the upgrade/credentials route process you get an "Error 500", then the remedy is to increase the PHP Memory.
  9. If you are using the 'names' module, you will need to add a patch to it prior to running upgrade. 
  10. Identify the database name and the MYSQL credentials for the Drupal 7 system. ideally, have it on the same LINUX server. Go to 
    • upgrade
      which will subsequently direct you to
    • upgrade/credentials
    • Enter the database and MySQL credentials
    • If an error occurs, Read the error message carefully. It may indicate a simple conflict or issue with an enabled module in the D8 (current) system.
    • If your D7 instance is using an excessive amount of modules then you may rn into dependency issues which prevent an automatic upgrade. resort to Plan B
  11. Plan B: custom migrate - This is a better option anyway because one is forced into examining the structure of the nodes and other entities within the database and perhaps consider a more logical design tweak for the new Drupal 8 upgraded instance.
    1. Get out a spreadsheet and write down the various content types within the D7 database. This process will create a separate custom migrate instance for each content type. The end result will be a set of nodes within the D8 Instance which will have identical nids (node ids) to the D7 database.
      • considerations
        • some content types may only have a limited number of nodes. If this is the case, evaluate whether it may be more efficient to simply "copy and paste" the content from one system to another. Of course, if maintaining the nids is important, you could create a very basic custom migrate that only migrates the nid and title, leaving the rest to be manually entered in a form.
        • If a content type contains reference entities and taxonomy terms, you may either want to create those migrations first.
      • process
        1. edit the D8 instance's settings.php file and add information to it about the D7 database. This is a preliminary step which will be referenced in about step 11.A.process.IV.d
          • just beneath the definition of the D8 database, add a second database definition for the Database.  Note the name to this database.
          • $databases['default']['default'] = array (  <br />
              'database' => 'd8-flanagan-rocks',<br />
              'username' => 'YOUCANONLYGUESS',<br />
              'password' => 'RUSTILLTRYINGTOGUESS',<br />
              'prefix' => '',<br />
              'host' => 'localhost',<br />
              'port' => '[someportnumber]',<br />
              'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',<br />
              'driver' => 'mysql', );<br />
            $databases['legacyD7']['default'] = array (<br />
              'database' => 'northconway-com',<br />
              'username' => 'YOUCANONLYGUESS',<br />
              'password' => 'RUSTILLTRYINGTOGUESS',

              'prefix' => '',<br />
              'host' => 'localhost',<br />
              'port' => '[someportnumber]',<br />
              'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',<br />
              'driver' => 'mysql', );
        2. create a content type within the D8 instance for each of the content types in the D7 instance
        3. create the set of fields within the D8 content types. term reference fields should contain the original tids from the D7 instance, so consider creating a custom migrate for the taxonomy first. Creating field groups within the D8 instance isn't necessary, but doing so might give you a head start in re-designing the UI for the D8 form, should any changes be introduced. 
        4. with matching content types created in the D8 instance, create a new custom module. This new module called d7migration, will handle the custom migrate. 
          1. create a directory off of the root called /modules/custom/d7migration.
          2. within the directory, create a file called d7migration.info.yml
            name: northConway 7 to 8 migration<br />
            type: module<br />
            description: defines the migration of content types and taxonomy terms from D7 instance to a D8 database.<br />
            core: 8.x<br />
            package: Custom<br />
            dependencies:<br />
              - migrate_drupal<br />
              - migrate_plus
          3. create another (set of) directory(s) inside of the module called /modules/custom/d7migration/config/install 
          4. within the install folder, create a file called migrate_plus.migration_group.dnc7.yml It's worth noting that the shared_configuration:source:key matches the database named within the settings.php file above in step 11.A.process.I , 'legacyD7'
            • id: dnc7<br />
              label: northConway 7 book<br />
              description: northConway D7 to D8 migrate book<br />
              source_type: Drupal 7.<br />
              shared_configuration:<br />
                source:<br />
                  key: legacyD7
          5. within the install folder, create a file called migrate_plus.migration.dnc7_bookct.yml which will hold the mappings from the D7 to the D8 instances' respective book content types.
          6.  

 

Source / Process / Destination

id: basics

label: Import articles

migrate groups:

  - ACME import

 

source:

  plugin: csv

  path 

 

Caveats

Rich Text (Long Text) fields that are being re-used across content types should have the same filtering options set on them within the content types; Migrate cannot act on Long Text fields which are defined in one Content-Type as being unfiltered while in others as being filtered.  It will simply skip the field in migration.

https://www.youtube.com/watch?v=eBP2vQIwx-o

Commands

drush ms / migrate-status

  - lists all of hte migrations that you have in your system

drush mi [migration name (from migrate-status)]

drush cim -y (configuaation importt

drush mr (migrate-revert) [namre of the migration]

 

 

within YML files, always check your white spaces .  strict, 2 spaces, no tabs

(refer to 16 minutes into video)

id: mbe_professors

# this id should match the yml file name

label: 'Import profesors''

source:

  plugin: csv

path: ../migrate/mbe_professorrs.csv 

# this is relative to where the configuration is stored

header_row_count: 1

keys: 

  - 'Professor ID'

process:

  type:

    plugin: default_value

default_valure: mbe_professor

  title: 'First name'

destination:

  plugin: 'entity:node'

Known Issues

https://www.drupal.org/docs/8/upgrade/known-issues-when-upgrading-from-drupal-6-or-7-to-drupal-8

custom migration to Drupal from 7

drush migrate-upgrade --configure-only --legacy-db-url='mysql://[username]:[password]@localhost/[mysql_database_name]'