Microsoft 365 & Modern Workplace

Microsoft 365 Collaboration Modernization

Prevvi Team

Microsoft 365 Collaboration Modernization

Client

A venture-backed biotechnology company in Greater Boston

Industry

Life Sciences

What was delivered

  • SharePoint information architecture
  • OneDrive deployment
  • Migration planning
  • Sync conflict cleanup
  • Executive workstation configuration
  • User adoption and training

Most collaboration problems are not software problems. They are architecture problems wearing a software costume. When a growing biotechnology company found its leadership and administrative teams fighting file duplication, sync conflicts, and documents that would not co-author, Prevvi was brought in to plan and implement a move onto Microsoft 365 done right.

The challenge

The client’s leadership and G&A teams worked across a patchwork of storage tools. Egnyte and Dropbox both synced folders to desktops, Office files lived in several places at once, and PowerPoint decks regularly hit co-authoring conflicts: two people editing what they thought was the same file, in two different systems.

The symptoms were familiar to anyone who has lived through tool sprawl:

  • Duplicate copies of the same document with diverging edits
  • Sync clients competing over the same folders
  • “Which version is real?” conversations before every board meeting
  • Executives losing time to file plumbing instead of decisions

What we delivered

Prevvi planned and implemented a collaboration strategy that moved Leadership and G&A onto Microsoft 365 with SharePoint and OneDrive as the system of record:

  • SharePoint information architecture: sites and libraries designed around how the teams actually work, not around an org chart diagram
  • OneDrive deployment and configuration for personal working files, with clear rules about what belongs where
  • Migration planning for Leadership and G&A, sequenced so nobody lost access mid-move
  • Egnyte and Dropbox synchronization cleanup, untangling competing sync clients from the same content
  • Resolution of PowerPoint and Office co-authoring conflicts by consolidating files onto one platform built for simultaneous editing
  • Executive workstation configuration and Office application remediation, so the tools worked cleanly on the machines leadership actually uses
  • User adoption and training, because a migration only counts when people change where they save

How we approached it

Architecture before migration

We designed the SharePoint structure first: which sites exist, who owns them, and how permissions flow. Migrating files into a well-designed structure is straightforward. Migrating them into an undesigned one just moves the mess to a new address.

One system of record per file

The root cause of the client’s duplication was that no rule said where a document lived. The new model made it unambiguous: team documents live in SharePoint, personal drafts live in OneDrive, and the legacy sync tools were cleanly detached from that content. Co-authoring conflicts disappear when there is only one canonical copy to edit.

Treat executives as a first-class rollout group

Leadership adoption decides whether a collaboration platform sticks. We configured executive workstations by hand, fixed the Office application issues that had eroded trust, and trained the teams on the small set of habits that matter: share links instead of attachments, edit in place, let versioning do its job.

Why co-authoring breaks, and how to fix it for good

Modern Office co-authoring works when everyone edits one copy of a file stored in SharePoint or OneDrive. It breaks when a second sync system inserts itself:

  • Two sync clients watching the same folder each upload their own “latest” version, creating conflicted copies.
  • A file opened from a desktop sync folder may be a stale local copy rather than the live cloud document.
  • Locking behavior differs across platforms, so one user’s editor holds the file hostage from another’s.

The durable fix is architectural: pick one platform as the system of record for a given set of content, remove competing sync clients from that content, and train people to open files from the canonical location.

The outcome

Leadership and G&A now collaborate on one platform with one copy of each document. Co-authoring works the way it is supposed to, duplication and sync conflicts stopped, and document accessibility improved for the people who need files fastest. The structure and rules are documented, so new hires inherit a system instead of a folklore. This kind of platform consolidation is a core part of our IT consulting and managed IT work.

Key takeaways

  • Design the information architecture before migrating a single file.
  • Every document needs exactly one system of record; two sync tools on one folder is a conflict factory.
  • Fix the executive experience first: leadership adoption carries the rollout.
  • Training on a few habits beats documentation nobody reads.

Frequently asked questions

Co-authoring conflicts almost always come from a second copy of the file: a competing sync tool watching the same folder, a stale local copy opened from a desktop sync client, or the same document living in two platforms at once. Office co-authoring works reliably only when everyone edits one canonical copy stored in SharePoint or OneDrive.

SharePoint is for team and company documents: shared libraries with defined ownership and permissions. OneDrive is for an individual's working files and drafts. The simplest durable rule is that anything more than one person needs lives in SharePoint, and personal drafts live in OneDrive until they are shared.

You can, but not on the same content. Two sync clients watching the same folders each upload their own latest version and generate conflicted copies. If you keep multiple platforms, give each one clearly separated content, and detach legacy sync tools from anything that moves into SharePoint or OneDrive.

It depends on how much content and how many teams are moving, but the sequence matters more than the calendar: design the SharePoint architecture first, migrate in planned waves so nobody loses access mid-move, then clean up legacy sync tools. Migrating into an undesigned structure just relocates the mess.

Treat leadership as a first-class rollout group: configure their machines individually, fix the application issues that eroded trust, and train a small set of habits such as sharing links instead of attachments and editing in place. When leadership adopts the platform, the rest of the organization follows.

Have a similar project in mind?

Talk to a real engineer about your environment: no sales script, just straight answers on how we would approach it.