Migrating Companyweb from SBS to Office 365 SharePoint Online

Microsoft Windows Small Business Server comes with a watered-down implementation of SharePoint called Companyweb (or WSS). Whether you are migrating from a full-blown SharePoint environment on-premises or the basic Windows Server-included Windows SharePoint Services, you are going to have to come to terms with one major migration hurdle:

Microsoft provides no real migration tools or best practices/methodology.

That’s the bad news. The good news is, folks like me are here to help. Here are some simple rules that serve to explain how a typical migration goes down, when coming from Companyweb/WSS 3.0, and moving forward on your way to Office 365.

1. 90% Planning, 10% Execution.

I usually set aside a week for most Small Business Server to Office 365 migrations. Minimum. If Companyweb is part of the picture, I always double this estimate to two weeks right out of the gate, giving SharePoint its own week. Since there are no official tools, and no official best migration path, it is usually a highly manual process (you can achieve some level of automation with 3rd party tools). Most of the process is discovery and recording down notes about what is actually being used, and then being careful when you actually go to move it.

Probably 95% of Small Businesses I encounter use Document Libraries primarily in SharePoint, and other features to a far lesser extent, like SharePoint calendars and some basic lists. However, if there are a lot of complex layers to a site–workflows, app integrations or customization that needs to come over, then this can extend your migration timeline even further.

2. Consider your options, including third-party tools.

You get three basic choices for a migration path:

• Manual copy
• Templates
• Third-party

Manual copy – Copying data from Companyweb into new Sites and Document Libraries can be time-consuming. The most common migration techniques used in small businesses are manual. For example, using the Windows Explorer method to drag and drop files & folders between libraries. Similarly you can attach different SharePoint calendars to an Outlook client and then copy content from one into another. For lists, you can export them into Excel, then import the list on the new site from there.

Unfortunately much is lost in manual copy jobs: past versions of documents will not come over, workflows would need to be recreated, and security/permissions have to be reapplied to name a few. Furthermore, if you drop connection or there is some other issue during data transfers, you will have no way of determining how much was left undone or where it failed during the process, and there is no way to sync “deltas” or changes that happened during a staged migration, either.

Templates – Another approach is to upgrade Companyweb into SharePoint Foundation Server 2013 on-premises first, and then move into Office 365 from there with a method called “templates”–which will allow you to export entire sites & document libraries, and preserve document history and metadata.  But not even this method is perfect, and you will still need to reset permissions, rebuild workflows, etc.

Third-party – Tools from third-party companies like ShareGate or AvePoint can make life a hell of a lot easier, but they do come with a cost. Being able to programmatically sync data and metadata, then resync it again later, can go a long ways in making a smooth transition to the new platform, and reducing overall migration time.

If all you are bringing over is a few Document Libraries and the client isn’t too concerned about the limitations of DIY migrations, it can be more cost effective to simply do it yourself, but man, outside of that… third-party assistance is awfully tempting, even if it does add cost to the migration.

3. Take this opportunity to clear out clutter.

Once data has been pushed into Office 365, most likely it will be staying there for a long while. So be sure you have a good handle on what is important to keep, and what you could probably do without–no sense in taking all the effort to move something that you don’t really need. This can be hard for business stakeholders because it forces them to make decisions about what data is really important to them. Project documents that represent failed past experiments may be functionally dead, but they can carry a lot of baggage in an emotional sense, which translates to difficulty letting go. Choose your battles wisely, and do not press for perfection.

4. Consider restructuring a little bit.

In my experience, most SMB’s use SharePoint primarily for the Document Libraries, but they typically treat these like file shares with complex folder structures. What a shame. The true power of SharePoint is left largely untapped (and can actually be more frustrating) if you use it this way. Instead, consider employing custom metadata, columns and views to categorize your documents instead of using many layers of sub-folders. This will greatly reduce time spent looking for information, and improve general usability.

5. Walk before you run.

SharePoint is a very big product in its own right, and it is tightly integrated with much of Office 365–enabling even more features than ever before such as the magical “Delve” application and of course OneDrive for Business. Then there is the PowerBI product as well…the list goes on. In short, Office 365 & SharePoint Online can be difficult to consume all at once.  It’s easier if you can adopt a few new features at a time. Besides migrating existing Document Libraries, Team Sites and so forth, consider transferring other functions previously fulfilled by file servers.

For example, OneDrive for Business is a pretty easy and intuitive application for most users–it is basically a replacement for redirected “Documents” (user-owned files), and you can easily sync these to any platform, including iOS and Android, much like Dropbox or similar. Implementing a bunch of other new tools and changes at the same time can make for a bad user experience, and poor adoption rates.  Build momentum with small wins like OneDrive first, and then move into the advanced stuff later.

Conclusion

Every Companyweb / SharePoint implementation tends to be a little bit different, and as such each project demands a different set of tasks. SharePoint is not even one of my strong suits at this point (working on it), and when my company picks up a heavyweight SharePoint project, I usually call in our “SharePoint guy” so that I can put my focus on everything else that happens with an SBS-to-365 migration. With no gold standard or best practice out there, it can certainly feel discouraging. Whatchagonnado? Call a Microsoft partner for help, that’s what.