Developing software in the Real World

Using Doctrine Migrations as a standalone tool

My current project has reached the point where a good migrations system is required. As I’m targeting two different database engines (MySQL and MS SQL Server) and we’re already using DBAL, it made sense to use Migrations from the Doctrine project.

To do this, I updated my composer.json with the following require statements:

in order to install Migrations and also Symfony console component so that I can run it from the command line.

The CLI script

Migrations doesn’t come with it’s own CLI script, so you have to create your own. Fortunately, we can tweak the supplied phar-cli-stub.php. I placed it in bin/migrations.php:

Note that, by default, the console commands are all prefixed with ‘migrations:’. This makes sense as usually they are integrated with the rest of the Doctrine ORM command line application and so it avoids any clashes. In this case, this script is only dealing with migrations and I don’t want to type more than I have to, so I remove the prefixes!


Migrations requires two separate configuration files to work: migrations.yml and migrations-db.php. These need to be in the current directory, so I used chdir() to ensure that it is in a known location – the application root in this case.

migrations.yml is the config file that tells Migrations the names of things:


In my case, I want to use my migrations files to be in a directory called migrations and use the namespace Migrations. The database table name that Migrations uses to keep track of its internal status is called migration_versions. I’m not too imaginative when it comes to naming things!

migrations-db.php must return an array that is used to configure Doctrine\DBAL\DriverManager::getConnection()


The documentation will help you find out what can go in here.

We’re now ready to go!

On the command line, php bin/migrations.php status should work:

Creating a migration

run php bin/migrations.php generate and a new migration class will be created in the migrations directory. It has two methods: up() and down(). Both have an instance of Doctrine\DBAL\Schema\Schema passed and an you can do whatever you like in the function to manipulate your database to its next state. Again, the documentation is helpful!

For instance:

Running the migration

Simply run php bin/migrations.php migrate and Migrations will the up() method for all migration classes that haven’t be run yet. In this case it will create a table called artists and update the migration_versions table with the version number of ‘20141027161210’.

To back out of a migration, simple run php bin/migrations.php migration {version number} and Migrations will run the appropriate down() (or up()) methods to get to that version number.

Finally you can run php bin/migrations.php status to find out the current state.

On the whole, it turns out that it’s quite easy to use Migrations as a stand-alone tool outside of Doctrine ORM or Symfony!

2 thoughts on “Using Doctrine Migrations as a standalone tool

Comments are closed.