Metadata Mapping in SharePoint Migration: What to Do When a Source Field Has No Home

TL;DR: 

Every source system stores information in its own way, and SharePoint won’t always have a column ready for it. When a source field has no matching column, it can disappear without any warning. This blog explains in plain words what to do about it, including how property mapping and value mapping work, using one simple example.

Say your old system tracks a field called “Review Status.” Every document has one: A for approved, R for rejected, D for draft. You migrate to SharePoint, and the library has no column for it. What happens?

Nothing loud. The files arrive and the count matches. The report says success. But “Review Status” is gone, until someone asks which documents were approved.

According to Gartner, 83% of data migration projects either fail or overrun their budgets and schedules. Many of those problems start small, with details like a field that never got a destination. These SharePoint migration issues stay hidden until users try to work with the content.

Metadata mapping is how you give every source field a home before the migration starts. This blog follows the “Review Status” example to show what to do when a field has no matching column, and how property mapping and value mapping each help.

Why Do Some Source Fields Have No Home in SharePoint?

No two systems are built in the same way. Documentum stores documents as objects with custom attributes. OpenText uses categories. FileNet uses document classes. SharePoint uses columns and content types.

Some fields line up neatly. “Title” goes to Title. Others may not. A field that made sense in the old system may have no matching column in SharePoint, and SharePoint won’t create one for you.

When that happens, someone decides what to do with the field before migration, or the field gets dropped. The second one is far more common.

What Is Metadata Mapping?

It’s a plain list that says: this source field goes to that SharePoint column. Two kinds of mapping do most of the work.

Property mapping connects a source field to a destination column. For example, the source field “Review Status” goes to a SharePoint column called “Approval Stage.”

Value mapping translates what’s inside the field. The source says A, R, or D. SharePoint expects Approved, Rejected, or Draft. Value mapping tells the migration that A means Approved, R means Rejected, and D means Draft.

You usually need both. Property mapping gets the field to the right place. Value mapping makes sure the content makes sense when it arrives.

What Can You Do When a Source Field Has No Matching Column?

You have five options:

1. Map it to an existing column. If a similar column already exists, use it.
2. Create a new column. Build it in SharePoint before migration, then map to it. This is the right call when the business actually uses the field.
3. Combine fields. Two source fields doing one job can feed a single column.
4. Convert the values. If the source values don’t match what SharePoint expects, use value mapping to translate them.
5. Leave it out on purpose. If nobody uses the field, drop it, but write down that you did.

The words that matter are “on purpose.” Dropping a field is okay. Dropping it by accident is the problem.

What Does This Look Like With “Review Status”?

Back to our example. The old system has a “Review Status” field on every document, with values A, R, and D. SharePoint has no column for it.

• Step 1: Ask the business. The team uses it to find approved documents. So it matters.
• Step 2: Create the column. Build a Choice column called “Approval Stage” with three options: Approved, Rejected, Draft.
• Step 3: Property mapping. Review Status goes to the Approval Stage.
• Step 4: Value mapping. A becomes Approved, R becomes Rejected, D becomes Draft.

After migration, every document arrives with its Approval Stage filled in. Search works. Filters work. The team finds what it needs.

If you skip these steps and the files still arrive. The report still says success. But nobody can tell an approved document from a draft.

Which Mistakes Cause the Most Trouble?

• Mapping only the obvious fields. Hidden ones like retention date, document type, and owner tags get missed.
• Skipping value mapping. The field arrives, but the values are codes nobody understands, or SharePoint rejects them.
• Creating columns after migration. The column has to exist before content arrives, or the values have nowhere to land.
• Not writing anything down. When a field is dropped, record why. Someone will ask later.

How Does Tzunami Help With Metadata Mapping?

Tzunami Deployer supports both property mapping and value mapping. Teams can connect source fields to SharePoint columns and translate values during migration, including from systems like Documentum, OpenText, and Confluence, where field structures differ a lot.

The tool carries out the decisions. The decisions still need to be made first: which fields matter, where they go, and what their values should become.

Summing Up

Metadata mapping prevents many problems discussed above. Give every source field a home, or a deliberate goodbye, before migration starts. That is how the new environment works on day one.

Frequently Asked Questions

1. What is metadata mapping in a SharePoint migration?
   It’s a list that connects each source field to a SharePoint column before migration begins.
2. What is the difference between property mapping and value mapping?
   Property mapping decides where a field goes. Value mapping decides what its values become.
3. What happens to a source field with no matching column?
   It can be dropped without warning, so the information is lost.
4. Should I create new columns before migration?
   Yes. The column must exist before content arrives, or the values have nowhere to go.
5. Can I leave a field out of the migration?
   Yes, if nobody uses it. Just record that you did it on purpose.
6. Does Tzunami support property and value mapping?
   Yes. Tzunami Deployer supports both.