Initial Question

Given an older CMS that kept data in a mysql database, how could we move this into a new D7 install?

It has a mysql database with a content table containing Title and Body (with HTML content) columns, could I do an import of this into Drupal and fill in the gaps as needed? I'm okay to rebuild menus and tie up other loose ends, but I'm fearing hours of cutting and pasting putting.

Follow Up and Outcome

:** After considering all the great advice below, I opened the older database in mysql Query Browser, executed a query on the profiles table to give me a CSV file with the following headers...

  • FirstName
  • MiddleName
  • LastName
  • Address1
  • Address2
  • phone
  • Email
  • title
  • cvFilePublic
  • pageContent
  • lastUpdateDate
  • pageName
  • pageURI
  • pageID

Then I created a Feed Importer with the following mapping:

enter image description here

3 Answers 3


The most quick and painless way would be to dump the old content from SQL to a CSV and import using Feeds - this can be done using a SQL program and point-and-click through Drupal. If this is a one-time thing, you should be fine with this. Feeds has mapping for most field types.

If you need to fully integrate, or do a more complex migration (import to field collections, for example, or do something other than create nodes) you can use migrate and directly query the other db then map the fields. This seems like overkill if you're just migrating title and body fields though. Again, I would use Feeds for something simple like this.


If you know any php I recommend the Migrate module to easily write a SELECT title, body FROM old_content and map them to Title and Body fields of a Drupal Page type. You would do this with a Migration class. See documentation on the project page.

You could also try the Feeds project.

There are modules for Migrate to migrate from Wordpress or older Drupal sites. You could use that as example migrations to move content, menus, etc into a new drupal site.

I've migrated pages, and custom Joomla content for courses and instructor content into Drupal content types .... but every migration use-case is always unique; I'm just recommending tools I've used.

  • +1 for Migrate. Cleanest and most powerful way to do data migrations into Drupal. Commented Feb 7, 2013 at 17:30

One option, though a decent amount of work, is to write a custom import script.

Typically, when I do this I will take the default index.php, copy it to something like import.php, and edit it to remove everything below the bootstrap code.

Then, I add in a loop to query the remote database, build up a node object from the results, and then do a node_save(). There are a few ways to build up node objects from scratch. A search will turn them up. Then I will browse to my import script and watch it run. Once the import is done, I will delete the script from the server.

This glosses over a fair number of details. The main advantage of this over Migrate or Feeds, is that it allows you to have more complex logic for how you handle the import, and more control over any data massaging. This is only an advantage, though, if you need these.

  • 1
    90% of the time I fall back to a manual import script too, it usually takes less time than what I estimate doing the same thing with migrate would
    – Clive
    Commented Feb 6, 2013 at 17:56
  • but then you dont get pretty drush/gui progress indicators :) or the whole "reset the migration" ... i dunno maybe i just see the implementation time as useful in that migrations offer a form of "standard" documentation as to how i moved stuff to this site (and the last 10 sites) ....
    – tenken
    Commented Feb 6, 2013 at 18:13
  • @tenken I think it just depends on the situation. The last few imports I have done have been simple enough for Feeds. A lot in the past, though, have required a lot of complex logic to massage the data. I just find it easier to bypass Migrate and do a one-off script. I also have done enough of these that I have a decent library to build from.
    – mpdonadio
    Commented Feb 6, 2013 at 22:22
  • A custom script will always require more time and offer much less than a Migrate solution, once you learn the rather basic Migrate concepts. Commented Feb 7, 2013 at 17:30
  • @BojanZivanovic After doing this a lot, I would respectfully disagree. You need to pick the best solution for your particular problem. Using Feeds or Migrate does work in a lot of instances. However, I have had been instances with content imports that are very complex (eg, take six loosely structured XML exports from custom systems, and weave together into four different content types, three taxonomies, and build up node references between everything). I have tried Migrate with these, and custom imports have always been quicker.
    – mpdonadio
    Commented Feb 7, 2013 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.