Entity framework code first - how to run Update-Database for production database

See Using Entity Framework (code first) migrations in production so that your application automatically updates the database when the Entity Framework initializes.

Now if you're more comfortable having manual control over the migration, you could use the -Script argument to the Update-Database command on your developer machine to generate SQL scripts which you can then run against the production database.

http://msdn.microsoft.com/en-us/data/jj591621.aspx (see Getting A SQL Script section)

Do you just want to automatically update the database to the latest version when and where ever your application runs (development and production)?

This may not be a good idea, except in very simple scenarios where you know you can trust automatic migration and manually migrating the database(s) is not feasible. Please see this answer: https://stackoverflow.com/a/15718190/2279059 . If you disregard this warning, read on.

Add the following to web.config:

<entityFramework>
<contexts>
  <context type="MyAssembly.MyContext, MyAssembly" disableDatabaseInitialization="false">
    <databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[MyAssembly.MyContext, MyAssembly], [MyAssembly.Migrations.Configuration, MyAssembly]], EntityFramework" />
  </context>
</contexts>

This may look scary, but it does basically the same as the following code:

Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, Migrations.Configuration>());

If you have no luck with web.config, then you may also try to put this code into Global.asax. I personally prefer configuration over code.

If you want your config file to look cleaner, you can also derive a new class from the template MigrateDatabaseToLatestVersion class so you don't need to use the cryptic syntax for passing type arguments in your web.cofig file:

public class MyDatabaseInitializer : public MigrateDatabaseToLatestVersion<MyContext, Migrations.Configuration> {}

What this does is to set a database initializer which automatically updates the database to the latest version.

(Source and more details: Entity Framework Code First Web.config Initialization)

To add on what @David said already...

Personally, I don't trust automatic updates in 'live' scenarios, and I always prefer manual database administration (i.e. there is a problem with permissions needed to create or alter Db - not to mention shared hosting etc.) - but from what I've seen migrations are pretty solid when it comes to synchronizing (in fact, the only way to 'untie' them normally is to remove the Db and force full/fresh update).

Here is a post I made a while ago on how to script and synchronize database / code and geared towards deployment scenarios (and when problems arise). It doesn't apply to you (yet) but something to keep in mind.

MVC3 and Code First Migrations - "model backing the 'blah' context has changed since the database was created"