The best approach to this will require some data grooming. At its simplest, it can be done with nothing besides stock Sitecore and the Sitecore Powershell module. If you're not comfortable with Powershell, or you need to take a more iterative approach, you could also write code to handle your transformation. I like to park pages in /sitecore/admin
for just such an occasion.
ORM Warning
If you are using an ORM solution such as Glass or Synthesis, you might want to avoid using it while you perform this merge, as duplicate names and duplicate inheritance may cause code generation issues.
Step 1: Create your new Interface analog
Create your new base template. For the time being, your base template should have a unique content section, so it's easy to find your new fields if you need to review them in the content editor.
Step 2: Establish Inheritance
Assign your new base templates to the target templates you want to merge. Don't delete the old fields; just add your new base template to the inheritance chain.
Step 3: The Heavy Lifting
You want to create a script that crawls the tree and does something like this:
- Disable security so you can grab all Items and modify them.
- Identify that an Item inherits from "New Base Template"
- Identify that an Item inherits from "Old Field Template"
- Assuming 1 & 2 are true, grab all versions of the Item via
Item.Versions
- For a given Version, copy the values from old-field to new-field.
- Save the version.
- Rinse, repeat.
At this point, all your items and their historic versions should have duplicate values in the old & new fields.
Step 4: Break the Chain
You can now break inheritance by removing the "Old Field Template" from the target Item Template. This will remove the old fields. If your target Item Template is the Old Template, go ahead & delete the fields. Warning, you may want to jot down the IDs of these old fields, so you can hunt them down in source code & configuration files if required
Step 5: Code Fixes
If your code is very plain, and you're referencing fields by field name ex: item.Fields["field name"]
you may not have any work to do. If you're using an ORM, you need to rebuild the classes using T4 templates, TDS, Unicorn, or Custom Item Generator. Assuming your new field names are the same as your old field names, once the ORM code is generated, you should be good to go, otherwise, you're in standard refactor land.
If you aren't using an ORM and you've got some sort of static FieldIDs class (a-la-Stock Sitecore) you're going to need to re-tool this class to point to your new FieldIDs.
The Warnings Come After the Spells
Depending on the size of your codebase, this is probably a good days work to write and test.
Ideally you'd want a content moratorium in production so that you could roll out the change in one go. If you have to re-run the Sitecore Template changes in production, I would consider using a tool like Razl for larger databases, possibly TDS for smaller ones.
If you have a lot of little sites, each with different Data Template groups (and ideally different VSProjects), I might consider doing this one site at a time.
For installations in the 50K to 100K Item range, I wouldn't hesitate, it'll save you trouble in the long run. If you're pushing a million Items, and/or you can't get any content authoring downtime, I would avoid attempting something like this until you could get a major system rebuild scheduled, or I would focus on redoing one site at a time. Assuming each site has their own Template folder (and therefore namespace) you shouldn't have issues with both approaches existing in the same system.