The Disadvantages of Installing Agents During a #SharePoint Migration

At Quest Software (now a part of Dell), we strive to providing the SharePoint community with solutions that provide maximum performance, power and flexibility, while minimizing the direct impact on your production systems.

What does this mean from a SharePoint migration perspective? In order to migrate content, our Migration Suite for SharePoint leverages Microsoft's published and supported APIs and Web Services, eliminating the need to install agents or other software on the source and target servers.

We choose this approach because there are many disadvantages to installing agents during a SharePoint migration.

Stability threat. Agents are code running on production servers using privileged accounts. They can do almost anything to SharePoint (and sometimes Windows). Should there be a bug in the agent code; consequences can range from minor system instabilities to data loss or service failures. Even if you can roll it back from backup, it will cause downtime for end users.

Software updates. With an agent-based architecture, installing new versions, updates, and patches is no easy task and requires careful planning. You will need to test the update to make sure it does not compromise stability, apply the update in the right order to all systems, and sometimes reboot servers.

Require network reconfiguration. Third-party agent software requires custom TCP ports to communicate with the main application. If the SharePoint servers are located on an isolated network segment or there are firewalls in-between, your network administrator will need to reconfigure the firewall rules to allow custom traffic.

Not Cloud compatible. In most cases, hosted SharePoint service providers forbid installing third-party software on their servers. So that means you can’t install agents in a standard SharePoint Online/Office 365 environments. One of the few exceptions is with Microsoft SharePoint Online Dedicated. Customers can use agent-based tools with SharePoint Online Dedicated, but Microsoft enforces a testing and certification process (called an HLD – High Level Design) for any third-party tools installed in the environment. Customers need to go through this HLD process that takes several days (and up to several weeks) to complete. Many agent-based tools are listed as “certified for SharePoint Online Dedicated/Office 365 migrations”. But those tools are certified because they need to be – because they install agents.

Not compatible with secure data centers. Even if you’re NEVER moving to the cloud, it doesn’t mean the cloud readiness doesn’t matter. Ironically, the compliance concerns that keep some enterprises away from the cloud also mean their data centers are cloud-like. That means that IT often has a hard rule about custom code and servers, and doesn’t allow third-party apps and agents to come into their data center. Period. So the cloud friendly, agentless approach is also a good one for regulated environments and secure data centers.

Lack of next version readiness. Everytime Microsoft releases a new version of SharePoint, migration tool agents need to be updated for the new version by their vendor and redeployed. Conversely, SharePoint remote APIs are forward compatible. So, the same product you are using now will work with the next version of SharePoint when you decide to move your content there.

Write to the database. Server-side installs sometimes (not always) bypass SharePoint and write directly to SQL Server for certain migration tasks. This is a violation of your Microsoft warranty.

Security loophole. Agents provide access to both the SharePoint engine and the underlying SQL database. Malicious persons can bypass regular SharePoint security and gain access to both SharePoint and your database.

Ignoring Microsoft's architectural direction. For years, Microsoft has been evolving away from a “one server does all” philosophy towards a diverse polyculture of interconnected specialized servers. That keeps each server clean. It’s also consistent with Internet based application design (LinkedIn, Facebook, etc.). We stopped installing custom apps directly on top of SQL and Exchange years ago. And we see this trend continue in SharePoint 2013 – Microsoft is moving ‘core’ functions like Office Web Apps, workflow, and custom applications to dedicated, independent servers. Adopting agents now is swimming against the tide.

So when evaluating a third-party SharePoint migration tool, remember that it's more than just moving content from point A to point B. It's important to consider the approach each tool takes.

About the Author

Daniel Gauntner

Dan Gauntner is a Senior Product Marketing Manager where he oversees the positioning and go-to-market strategy for Office 365, Active Directory, Exchange, Lotus Notes, SharePoint and OneDrive for Business...