Implementing traffic isolation can be a fairly straightforward process depending upon the existing network configuration and design.
Let’s consider a typical small SharePoint deployment that consists of one database server, one application server, two web servers and a directory server. In many cases, these components all have a single network interface connected to a shared switch. A more efficient approach would be to utilize multiple network interfaces in each server and connect them to virtual local area networks (VLAN) on the same switch. For example, the web servers may have three interfaces, one which connects to the corporate network, one which connects to an authentication network, and one which connects to a database network. In this manner traffic between the web servers and the database, which comprises the bulk of SharePoint network communication, can be isolated to a single interface separate from the interface used by employees to browse pages and upload files. Similarly, communication with directory services to facilitate logins and authentication requests will have its own channel to exchange information. Another very useful technique is to configure SharePoint services that generate a lot of network traffic, like search, to only communicate with a dedicated server instead of the general-purpose web servers.
Once your on-premises network is optimized you are in a better position to consider moving data to the cloud and deploy hybrid services. Office 365 supports automated means of moving large quantities of data, but speeds as low as 1 gigabyte per hour are not uncommon. So clearly there is a need for not only proper planning of time and resource allocation, but also incoming and outgoing bandwidth. On-premises servers need to be running optimally, as migration tasks consume additional bandwidth on top of normal collaboration activities, and external links must be optimized to facilitate a great deal more traffic than normal day-to-day web browsing.