Basically migrations are a way to introduce a versioning system to your databases. Using migrations you can keep track of the changes made to your schema and use them to update your database tables without the usual pain of dropping your database and re-generating it with an updated schema.
Doctrine, as with other ORMs, implements migrations by creating files which create, update or delete tables and columns. Doctrine's migration files are just classes that extend the Doctrine_Migration class. These classes use methods to manipulate your database's tables and columns. Basically Doctrine generates one file per version which will hold all the changes that are needed to update the database to this version from the previous version.
Migrations add a powerful tool to your symfony toolbox when it comes down to manipulating or updating your project databases. With migration based versioning you gain the ability to update (and downgrade) your database from one version to another whilst decreasing the chance that such updates will break your data.
For example - you can update your database at computer A to the schema of computer B without dropping and re-generating it again. You may think that this only helpful when you are developing applications in teams where multiple developers work with on the schema of the database, however migrations have numerous applications even in single-developer environments - most notably to help update live databases after making changes to your code and your database schema.
In the last paragraph I mentioned team development. Migrations will never replace SCM tools like svn or git. Nor can migrations handle situations where two developers added migrations at the same time and expect Doctrine to do the merging. You will still have to keep track of your database changes and add migrations wisely and one after another.