By adding the -ContextTypeName  and -MigrationDirectory flags, Entity Framework 6 added support for multiple DbContext' s.  If you have 2 or more DbContexts in your solution and you try to run enable-migrations in the Package Manager Console, you will receive the following error :

PM> enable-migrations
More than one context type was found in the assembly 'WebApplication3'.
To enable migrations for 'WebApplication3.Models.ApplicationDbContext', use Enable-Migrations -ContextTypeName WebApplication3.Models.ApplicationDbContext.
To enable migrations for 'WebApplication3.Models.AnotherDbContext', use Enable-Migrations -ContextTypeName WebApplication3.Models.AnotherDbContext.

 To avoid this error you need to run enable-migrations on each DbContext in the solution and specify a folder were each Configuration.cs file will be generated, seperately. This is how our Package Manager Console looks after enabling migrations on two different DbContexts :

PM> Enable-Migrations -ContextTypeName ApplicationDbContext -MigrationsDirectory Migrations\ApplicationDbContext
Checking if the context targets an existing database...
Code First Migrations enabled for project WebApplication3.

PM> Enable-Migrations -ContextTypeName AnotherDbContext -MigrationsDirectory Migrations\AnotherDbContext
Checking if the context targets an existing database...
Code First Migrations enabled for project WebApplication3.

When you add-migration for the DbContexts you have to specify a fully qualified name for each configuration class:

PM> Add-Migration -ConfigurationTypeName WebApplication3.Migrations.ApplicationDbContext.Configuration "InitialDatabaseCreation"Scaffolding migration 'InitialDatabaseCreation'.
The Designer Code for this migration file includes a snapshot of your current Code First model. 
This snapshot is used to calculate the changes to your model when you scaffold the next migration. 
If you make additional changes to your model that you want to include in this migration, then you can re-scaffold it by running 'Add-Migration InitialDatabaseCreation' again.

PM> Add-Migration -ConfigurationTypeName WebApplication3.Migrations.AnotherDbContext.Configuration "InitialDatabaseCreation"
Scaffolding migration 'InitialDatabaseCreation'.
The Designer Code for this migration file includes a snapshot of your current Code First model. This snapshot is used to calculate the changes to your model when you scaffold the next migration. If you make additional changes to your model that you want to include in this migration, then you can re-scaffold it by running 'Add-Migration InitialDatabaseCreation' again.

The following update-database works exactly the same way, you have to update each DbContext with is own update command in the Package Manager Console :

PM> Update-Database -ConfigurationTypeName WebApplication3.Migrations.ApplicationDbContext.Configuration
Specify 
the '-Verbose' flag to view the SQL statements being applied to the target database.
Applying explicit migrations: [201402032113124_InitialDatabaseCreation].
Applying explicit migration: 201402032113124_InitialDatabaseCreation.
Running Seed method.
PM> Update-Database -ConfigurationTypeName WebApplication3.Migrations.AnotherDbContext.Configuration
Specify the '-Verbose' flag to view the SQL statements being applied to the target database.
Applying explicit migrations: [201402032113383_InitialDatabaseCreation].
Applying explicit migration: 201402032113383_InitialDatabaseCreation.
Running Seed method.

You can share the same connection string for each context. To be on the safe side you need to make sure that they do not map to the same tables. If you do have migrations that map to the same table you can still define a migration to run first. The first migration file will then create the table while the second migration needs to be modified so that is  will update/modify the table and not create the already existing table. Afterwards you  can then use MigrateDatabaseToLatestVersion, forsing the Database.Initialize() of each context to run in the correct order. You can also run the update-database command in the correct order manually, and vice versa  if you want to do a migration to a previous version. This approach is very dangerous, so be careful.  

Inspired by answer on stack overflow from Anthony Chu, multiple-db-contexts-in-the-same-db-and-application-in-ef-6-and-code-first-migra