I'm a huge advocate of minimalist or simple design. What I mean by this is do not write code for the "maybe one day" or "we may want to". Just write the code that meets the requirements. Do not try and write code today for requirements that may come in the future.

I've been working on a new implementation of my website that uses AngularJS for the frontend. During my initial development I created three projects named Core, Tests, and Website. You can probable guess what each project contained. Now I'm planning on adding a phone client and maybe even a tablet client. Now I want to move my data layer into it's own assembly so my phone and tablet app do not have to take on the Entity Framework dependency for they will not need it.

I created a new project called Data and proceeded to move all my Entity Framework specific code into the project. Everything migrated very easily and in about 10-15m I had my new data layer in it's own assemblies. Everything compiled and all my unit test passed. However when I went to do some smoke testing I found that my data context was trying to apply old migrations... hum.

So who moved my migrations? Oh that's right I did. My migration configuration was previously located at EpicCoders.Migrations.Configuration but now it has moved to EpicCoders.Data.Migrations.Configuration. This means that Entity Framework is looking at the Migration's table ContextKey value to associate migration to the data context. I needed to set my ContextKey in the constructor of the migration configuration class to the previous location as to keep the same key value.

ContextKey = "EpicCoders.Migrations.Configuration";

Now my migration configuration will associate the old migrations to the "new" configuration.