Bandwidth Considerations When Eliminating PST Files

Print Friendly, PDF & Email

A direct route to PST migrationWe all hate detours, they add extra miles, extra time and a great deal of uncertainty to our journeys. Much better to get to our destination directly with the shortest, quickest route.   The same holds true for PST Elimination / PST Migration projects.

I frequently use this analogy when discussing projects with customers and prospects, and, the bigger the scope of the project the more relevant it is.

Choosing the right path

In technical terms it is all about the route the PST data takes in order to get to its final destination.

The first generation products on the market all advocate gathering all the remote PST files onto a central server and then ingesting from that server into the mailbox. At first glance that seems sensible, giving us a controlled environment from which to do the ultimate ingestion.

Only when considering it further and examining the wider implications does it become clear that this approach is fundamentally flawed. Looking at the steps involved in that process:

1. Get the PST from the remote workstation/laptop to the central server

  • Copy the PST and risk the user modifying content after the copy?
  • Move the PST and have the user lose access to it whilst it is moved/ingested?
  • Network bandwidth consumed by the move or copy?
  • What are the boundaries for moves/copies – (across offices?, from home users on VPN?, across continents?)

2. Ingest the PST into the final destination (Exchange/Archive/Office365 etc)

  • Network bandwidth consumed by the ingestion?
  • Network bandwidth consumed by the ingested data being synchronised back to the users OST?
  • What are the boundaries for the ingestion – (across offices?, across continents?)

Even if you exclude the issues about access to the PSTs during the project and moving across network boundaries, there is a key point here.  The data is moving across the network THREE times. THREE times.

It's all about getting from A to B

A recent large customer I was talking to has 400TB of PST data. That would mean 1.2 PETABYTES of data they would have to move across their network with any of the older, first generation products.

What the customer loved about the C2C PST Enterprise product was the ability to move the data just ONCE … directly from the remote workstation/laptop into the Exchange/Office365 server the user is already connected to (usually the closest in network terms).   Also, while the migration is taking place the user maintain full access to the PST – adding/removing /editing items in it.

We were able to help them navigate the quickest and direct route as simply as from A to B.   No detours, no stopovers, u-turns or changes.

Scroll to top