text: Q:
  
  Which is better for database seeding: Add or AddOrUpdate?
  
  I don't understand why it is recommended everywhere to use AddOrUpdate in the Seed method?
  We develop application for half a year already and the AddOrUpdates overwrites user changes every time we update the server. E.g. if we call in the Seed:
  context.Styles.AddOrUpdate(new Style { Id = 1,  Color = "red"  });
  
  And user changes the Style to "green" then on next server update we overwrite it to "red" again and we get very annoyed user.
  It looks that if we change AddOrUpdate to Add we will be guaranteed from overwriting user data. If we still need some special case we can put it to separate migration. Unlike the general Configuration.Seed method particular migrations don't run twice over the same database version. 
  
  A:
  
  I assume that Style's primary key is Id. The overload of AddOrUpdate that you use only checks if there is a record having Id == 1. If so, it updates it. That's all.
  What's going wrong here is that the primary key is a surrogate key, i.e. it's there for querying convenience, but it's got no business meaning. Usually, with migrations you want to look for the natural keys of entities though. That's how the user identifies data. S/he wants a green style, not a style identified by 1.
  So I think you should use this overload of AddOrUpdate:
  context.Styles.AddOrUpdate( s => s.Color,
                              new Style { Id = 1,  Color = "red"  });
  
  Now when there is no red style anymore, a new one is inserted, overriding the Id value (assuming that it's generated by the database).
  From your later comments I understand that you want to Add data when they're new, but not update them when they exist (compared by primary key). For this you could use a slightly adapted version of an AddWhenNew method I described here. For your case I would do it like so:
  public T void MarkAsAddedWhenNew<T>(this DbContext context, 
          Expression<Func<T, object>> identifierExpression, T item) 
      where T : class
  {
      context.Set<T>().AddOrUpdate(identifierExpression, item);
      if (context.Entry(item).State != System.Data.Entity.EntityState.Added)
      {
          var identifierFunction = identifierExpression.Compile();
          item = context.Set<T>()
                 .Local
                 .Single(x => identifierFunction(item)
                              .Equals(identifierFunction(x)));
          context.Entry(item).State = System.Data.Entity.EntityState.Unchanged;
      }
      return item;
  }
  
  Re-fetching the item from the local collection is a nuisance, but necessary because of a bug in AddOrUpdate(). This bug also caused the error you got when setting the state of the original entry to Unchanged: it was a different instance than the attached one.
  
  