Microsoft SharePoint 2007 Technologies

10.9 Planning Data Migrations 219

Chapter 10

backup and restore capabilities for SharePoint 2003. Today, there are also a

number of other products available from vendors, such as Veritas Backup

Exec. Keep an eye on the Microsoft Office System Solutions Directory for

updates on Backup, as well as other add-on products for SharePoint at

http://directory.partners.extranet.microsoft.com/.

10.9 Planning Data Migrations

Even though migration from a legacy platform might not be part of your

deployment plan, it is highly likely you will be faced with migrations sooner

or later, be it migrations within your SharePoint deployment or from other

platforms. After all, maintaining and supporting disparate knowledge envi-

ronments is not only costly from an operational and support perspective, but

it also creates knowledge silos that prevent effective sharing of knowledge,

experiences, and best practices within an enterprise.

Although one might consider migrations as mainly taking data from

System A to System B, a much more likely and common migration scenario

is to actually move data within the same product. Having separate develop-

ment, staging, and production environments is common place in any enter-

prise application deployment and often moving data between these

environments is part of a production deployment cycle. In regionalized

deployments, moving production data is commonplace, due to changing

network conditions and users changing locations, not to mention consolidat-

ing infrastructures to a central farmed deployment from previous single

server configurations. More far-reaching changes, such as mergers or divesti-

tures, can also prompt the consolidation or separation of data.

10.9.1 When Company Structures Change

Many of us have been involved in bringing the IT landscape of an enterprise

to a steady harmony after a merger, but we suspect few of us have also been

involved with figuring out how to separate enterprise systems after a divesti-

ture. From experience, we can vouch that these mergers can even occur while

deploying a technology only to find that your new colleagues are in the pro-

cess of doing the same. While neither task is without challenges for an enter-

prise deployment of SharePoint, a merger is typically more straightforward to

plan out and execute than a divestiture.

Typically, the first step to providing interoperability during a merger is

to ensure that the two domain infrastructures trust each other and that net-

work connectivity exists between the two companies. When HP and Com-

paq underwent the largest IT merger in history, we talked about “Day 1”

interoperability, which included both network bridges and domain trusts.

Thus on Day 1 of the merger, both company’s SharePoint environments