Sorry, I discovered that initially we wrote a test for different case (propagation to derived type), so it took some time to test and described this.

First of all, there is no easy way to do this now - mainly, because there is no hint allowing to merge two types into one. So if you need to merge

Upgrade way 1: RDBMS-indepenent, based on schema hints

Old model:

[HierarchyRoot]
public class Base : Entity
{
  [Field, Key]
  public long Id { get; private set; }
}

public class Derived : Base
{
  [Field]
  public string Text { get; set; }
}

New model:

[HierarchyRoot]
public class Base : Entity
{
  [Field, Key]
  public long Id { get; private set; }

  [Field]
  public string Text { get; set; }
}

// It's necessary to keep the data till the final stage of upgrade;
// but note we converted this type to hierarchy root.
[HierarchyRoot]
[Recycled, Obsolete]
public class Derived : Entity
{
  // Necessary, because this is a hierarchy root now!
  [Field, Key]
  public long Id { get; private set; }

  [Field]
  public string Text { get; set; }
}

Overriding OnSchemaReady method in UpgradeHandler:

public override void OnSchemaReady()
{
  // Table names can actually be extracted from models,
  // but I'm intentionally simplifying the code here

  string baseTableNodePath = "Tables/Base";
  string baseTableColumnPath = "Tables/Base/Columns/";
  string derivedTableNodePath = "Tables/Derived";
  string derivedTableColumnPath = "Tables/Derived/Columns/";

  if (UpgradeContext.Stage==UpgradeStage.Upgrading) {
    // Replacing Dervided type's TypeId in Base table
    // to Base type's TypeId; if there are many ancestors,
    // this action must be performed for each of them.
    UpgradeContext.SchemaHints.Add(new UpdateDataHint(
      baseTableNodePath,
      new List<IdentityPair> {
        new IdentityPair(baseTableColumnPath + "TypeId",
          UpgradeContext.ExtractedTypeMap[typeof (Derived).FullName].ToString(), true)
      },
      new List<Pair<string, object>> {
        new Pair<string, object>(baseTableColumnPath + "TypeId",
          UpgradeContext.ExtractedTypeMap[typeof (Base).FullName])
      }));
  }
  if (UpgradeContext.Stage==UpgradeStage.Final) {
    // Copying the data from "Text" column in "Dervided" table
    // to "Base" table.
    UpgradeContext.SchemaHints.Add(new CopyDataHint(
      derivedTableNodePath,
      new List<IdentityPair> {
        new IdentityPair(
          derivedTableColumnPath + "Id", baseTableColumnPath + "Id", false)
      },
      new List<Pair<string>> {
        new Pair<string>(
          derivedTableColumnPath + "Text", baseTableColumnPath + "Text"),
      }));
  }
}

The description:

• We convert Derived type to a hierarchy root that must be recycled on final stage of upgrade
• On Upgrade stage: we remap TypeId of old type to new one using schema hint
• On Final stage: we copy the data from Text column by the same way.

The following SQL is executed in this case:

UPDATE [dbo].[Base] SET [TypeId] = 101 
WHERE ([Base].[TypeId] = '102');
...
UPDATE [dbo].[Base] SET [Text] = [th].[Text] FROM (
  SELECT [a].[Id], [a].[Text] FROM [dbo].[Derived] [a]) [th] 
WHERE ([Base].[Id] = [th].[Id]);

So it's nearly the fastest way to perform such upgrade.

Upgrade way 2: RDBMS-dependent, based on direct SQL execution

Models are the same.

Overriding OnStage method in UpgradeHandler:

public override void OnStage()
{
  var session = Session.Demand();
  var directSql = session.Services.Demand<DirectSqlAccessor>();
  if (!directSql.IsAvailable)
    return; // IMDB, so there is nothing to uprade
  if (UpgradeContext.Stage==UpgradeStage.Initializing) {
    // Relying on Metadata.Type, because
    // only system types are registered in model @ this stage.
    int baseTypeId = Query.All<Metadata.Type>()
      .Where(t => t.Name==typeof(Base).FullName).Single().Id;
    int derivedTypeId = Query.All<Metadata.Type>()
      .Where(t => t.Name==typeof(Derived).FullName).Single().Id;
    var command = directSql.CreateCommand();
    command.CommandText = @"
      UPDATE [dbo].[Base] SET [TypeId] = {0} 
      WHERE ([Base].[TypeId] = {1});
      ".FormatWith(baseTypeId, derivedTypeId);
    command.ExecuteNonQuery();
  }
  if (UpgradeContext.Stage==UpgradeStage.Upgrading) {
    var command = directSql.CreateCommand();
    command.CommandText = @"
      UPDATE [dbo].[Base] SET [Text] = [th].[Text] FROM (
        SELECT [a].[Id], [a].[Text] FROM [dbo].[Derived] [a]) [th] 
      WHERE ([Base].[Id] = [th].[Id]);

      DELETE FROM [dbo].[Derived];
      ";
    command.ExecuteNonQuery();
  }
}

As you see, we do nearly the same, but using direct SQL commands. You might notice we use different upgrade stages here - that's because schema hints must be generated in the same stage when schema changes, but OnStage method is executed when domain is already built, i.e. after schema changes. That's why we use earlier stages here.

Upgrade way 3: RDBMS-independent, based on custom upgrade code

You may find that usage of direct SQL commands is actually an optimization in previous case. You can achieve the same with this OnStage code:

public override void  OnStage()
{
  if (UpgradeContext.Stage==UpgradeStage.Upgrading) {
    foreach (var derived in Query.All<Derived>()) {
      new Base {Text = derived.Text};
    }
  }
}

And actually, I'd advise you to use such code. It's slower than a single update, but must be pretty good as well (DO batches everything batching). But it's easier to understand and refactor.

So use this approach, if upgrade performance isn't essential.

Conclusion

As you see, the process is a bit tricky first two cases, but such upgrades are possible. The third option is pretty simple, so likely, it will be the best choice in majority of cases.

Custom upgrade handler must help here:

1. Put [Recycled, Obsolete] @ class B, but leave it.
2. Make necessary changes in class A (add Text field)
3. Add custom upgrade handler with the code described below.

Upgrade handler code, option 1 (custom upgrade code):

public class Upgrader : UpgradeHandler
{
  public override void OnUpgrade()
  {
    foreach (var b in Query.All<B>())
      new A { Text = b.Text };
  }

  public override bool CanUpgradeFrom(string oldVersion)
  {
    return oldVersion=="1.0";
    // return base.CanUpgradeFrom(oldVersion); // Either the same version, 
    //                                         // or a new DB.
  }
}

Upgrade handler code, option 2 (with upgrade hints):

public class Upgrader : UpgradeHandler
{
  protected override void AddUpgradeHints(ISet<UpgradeHint> hints)
  {
    hints.Add(new RenameTypeHint(typeof (B).FullName, typeof (A)));
    hints.Add(new CopyFieldHint(typeof (B).FullName, "Text", typeof (A)));
    // Or, if B is already deleted (i.e. no any [Recycled, Obsolete]):
    // hints.Add(new RenameTypeHint("BNamespace.B", typeof (A)));
    // hints.Add(new CopyFieldHint("BNamespace.B", "Text", typeof (A)));
  }

  public override bool CanUpgradeFrom(string oldVersion)
  {
    return oldVersion=="1.0";
    // return base.CanUpgradeFrom(oldVersion); // Either the same version, 
    //                                         // or a new DB.
  }
}

Difference between these two versions:

• First version implies old B instanced are destroyed, but new A instances are created. I.e. if there were references to Bs, they'll be nullified. To keep them, you must manually write the code doing this in OnUpgrade method (i.e. finding all references pointing to old B instances and changing them to corresponding A instances). Btw, you can use ReferenceFinder to do this - it operates quite efficiently.
• Second version does not recreate anything - it is purely hint-based solution. You don't need to keep [Recycled, Obsolete] public class B there.

Upgrade handler is a regular class inherited from Xtensive.Storage.Upgrade.UpgradeHandler, that must be registered in DomainConfiguration.Types - normally, as part of the whole assembly with persistent types.