There’s so much going on in the world of Drupal migrations. Drupal 9 reached its End Of Life (EOL) on November 1, 2023. Drupal 7 will reach EOL by January 2025 (final extension). Drupal 10 was released back in December 2022 and its current version, 10.1.6 was released on November 1, 2023. More than twelve thousand sites have already migrated to the current version of Drupal 10 (according to the Upgrade Status module download stats).
In this article, we’ll take you through the different Drupal migration methods and especially focus on custom migrations using the SqlBase source plugin. Take a look!

In Technical Terms, What is a Drupal Migration?
Drupal migration is the process of moving content, data, and configuration from another CMS (or an older version of Drupal) to Drupal. A migration consists of several steps: Extract, Transform, and Load (ETL). In the Drupal world, we refer to these as source plugins, process plugins, and destination plugins. The Extract phase is known as the source, Transform is the process, and Load is the destination.
Drupal Migration Methods
When migrating your website from Drupal 7 to Drupal 9 or a later version, there are primarily two migration methods available.
Migration UI 
Drush (Custom migration)
Migration UI 
When you want to migrate your entire web application, including all configurations and content, to a later version, you can use Migration UI. It’s a straightforward option that doesn’t require in-depth knowledge of Drupal APIs. This approach can be used where your site is not too complex in terms of site architecture and considering all the modules used in Drupal 7 are also available in the target version (Drupal 9 or Drupal 10).
Custom Migration
When you are rewriting your website with a more modern and performance-centric approach which leads to significant changes in the architecture of your new website from Drupal 9, Migration UI literally won’t work. In such cases, you’ll need to roll up your sleeves and build custom migration scripts.
Migration Process
Let’s dig deeper into the migration process. It comprises of 3 major processes.
Source plugin (Extract)
Process plugin (Transform)
Destination plugin (Load)
Source Plugin
Source plugins handle the extraction of data from various sources, which can be in different formats, including raw data, databases, and CSV/XML/JSON files. They extract data from these sources and pass it on to the next phase in the migration process.
Process Plugin
The process plugin works on the source data, restructuring it to match the destination process. It transforms the data into an array, where each key corresponds to a destination property. The values assigned to each key determine how the destination values for your new website are generated.
More details can be found here.
Destination plugin
The destination plugin processes the structured data and saves it on your website. The most common destination plugins are node, term, user, and media.
You likely have a grasp of the migration process. Now, let’s delve deeper into source plugins, with a specific focus on the SqlBase source plugin.

Thinking of migrating your Drupal 7 website to Drupal 10? Get your Drupal 7 Site Audit report for Free!
Using SqlBase for the Drupal Migration
What is SqlBase migration?
SqlBase migration is straightforward—it allows you the flexibility to create your custom SQL queries to obtain the desired output. Other than that, it follows the same principles as other Drupal migration methods.
Why should you use SqlBase Migration?
When your site has a straightforward field structure, content types, etc., Drupal core migration can handle it. However, challenges arise with obsolete field types in Drupal 9 or when restructuring an old website with various content types. If you aim for an editor-friendly and performance-oriented site, a simple migration won’t suffice. You’ll need to prepare your source data and take the SqlBase migration route.
In another scenario, if your current site, built on a platform other than Drupal, provides data in the form of a database, SqlBase migration is also the way to go.
Benefits of leveraging SqlBase Migration
Since this is SqlBase, the speed of your migration relies entirely on how well you craft your database queries. The better your query preparation, the faster the migration will run.
It doesn’t rely on many core migration processes; you have the flexibility to shape and process your data as you see fit.
The SqlBase Source Plugin must implement these three methods:
query(): Returns the SQL query that selects the data from the source database.
fields(): Returns available fields on the source.
getIds(): Defines the source fields uniquely identifying a source row
Let’s get into the details of what these functions should contain:
query() function
/**
* {@inheritdoc}
*/
public function query() {
$query = $this->select(‘job_details’, ‘c’)
->fields(‘c’, array(
‘id’,
‘title’,
‘description’,o
‘position’,
‘company’,
‘criteria’,
));
return $query;
}fields() function
/**
* {@inheritdoc}
*/
public function fields() {
$fields = array(
‘id’= $this->t(‘Autoincrement ID’),
‘title’ = $this->t(‘Job Title’),
‘description’ = $this->t(‘Job Description’),
‘position’ = $this->t(‘Job Position’),
‘company’.= $this->t(‘Company’),
‘criteria’ = $this-»t(‘Job Criteria’),
);
return $fields;
}getIds() function
/**
* {@inheritdoc}
*/
public function getIds() {
return [
‘id’ => [
‘type’ => ‘integer’,
‘alias’=>’j’
];
}Additionally, you can tweak your SQL result by using the prepareRow() function and even add new source properties to your migration.
/**
* {@inheritdoc}
*/
public function prepareRow(Row $row) {
$company = $row->getSourceProperty(‘company’);

$row->setSourceProperty(‘job_type’, ‘on-site’);
if ($company == ‘specbee’) {
$row->setSourceProperty(‘job_type’, ‘remote’);
｝

return parent::prepareRow($row);
}These source properties will be sent to your migration yml files and you can also use your own processor if you want any additional processing on your source data.
Referenceshttps://www.drupal.org/project/usage/3398311
Final Thoughts
With Drupal 9’s EOL, the impending farewell to Drupal 7, and the rise of Drupal 10, the need for seamless transitions has never been more pressing. As Drupal evolves, our Drupal Development Company recognizes SqlBase as an essential tool for a seamless and efficient migration process. Offering the flexibility to shape personalized SQL queries, it plays a vital role in crafting tailored data transitions. If you’re looking for a reliable Drupal migration partner, we’re just a form away! 

This is the continuation of my previous post regarding the Lesli SaaS Framework. This time, I’d like to explore further into the Lesli gem.

Recently, I saw this article regarding ObjCs “end of life” from JetBrains.

The tiobe index seems to disagree. It’s also important to remember that jetbrains recently had to take down their AppCode application (which sucked) since it didn’t sell.

Jetbrains is the creator of the kotlin language so they have a vested interest in their android customers. I would take their “index” with a grain of salt to say the least.

While it is certain that Apple won’t be investing into thing beyond ObjC 2.0, it is foolhardy to think that ObjC is going away anytime soon since there is an enormous installed base of stable code, not the least of which is Foundation and AppKit themselves. Also consider CocoaPods.

So, no, not worried about it. Also… look at Java and COBOL. For years people have declared the end of both languages. Java is still popular, though not in vogue and COBOL while not one of the “cool kids” has literally billions of lines of code being maintained and new code being written every year. This (admittedly biased as it is by the CTO of MicroFocus) article gives some reasons why….

Here is the article about COBOL…

Plus… Apple already has a mechanism for automatically allowing objc and swift to work together. Take a look at the frameworks in Xcode and you’ll notice some files called *.apinotes. These are YAML files that are used by the compiler to allow easy integration into swift projects. So, essentially, if Apple writes an ObjC version of a framework they get the swift version for absolutely free (minus the cost of writing the YAML file). If they write a swift only version they don’t get that benefit.

So, yeah, in conclusion… Yes, ObjC is NOT on the rise, but reports of its demise have been greatly exaggerated! 😉

PS. That being said, Apple dumping ObjC might spell a boom for us as all of the people who have installed codebases would suddenly need support for it either on macOS (on which we don’t currently work) or on other platforms. Something to think about…

PPS. All of the above being said. I admit I wouldn’t be terribly shocked to hear from Apple that “we have dropped support for the legacy objc language to provide you with the best support for our new swift language to make it the ‘greatest developer experience in the world’” or some grotesque BS like that. Lol

GC

FreeBSD has supported nesting of jails natively since version 8.0, which dates back to 2009. Looking at the jail(8) man page, there is an entire paragraph named Hierarchical Jails that explains the concept of jail hierarchy well. It’s one of the many gems of FreeBSD that, although not widely known or used, is, in my opinion, extremely useful. BastilleBSD plays a central role in this article, and that’s a project I’ve been hearing a lot about recently. I feel like the various BSDs are currently hitting a stride, and there seems to be a lot of movement from Linux to BSD at the moment.