IT projects / Where the promise gets kept
Every page here says a migration sits outside recurring service. This is that promise, kept.
A mailbox migration, a new application rollout, or the IT buildout for a new office is real work that does not fit inside a monthly per-user rate. This page explains how that kind of scoped project actually gets estimated, run, and handed back into the everyday rhythm.
Lire cette page en françaisWhy projects are scoped separately
Recurring service assumes a steady environment. A project changes it.
Recurring service assumes a relatively steady environment: the same users, the same systems, ongoing attention. A project changes that environment on purpose — new software, a new location, a migrated mailbox — and needs its own estimate, timeline, and acceptance criteria instead of being absorbed quietly into a support queue.
Common projects
What they actually involve.
| Project type | What has to be scoped | Typical dependency |
|---|---|---|
| Mailbox or platform migration | Data volume, downtime tolerance, and a cutover plan | Vendor migration tools and a tested rollback |
| Line-of-business application rollout | Licensing, data migration, and user training | The software vendor's own implementation requirements |
| New-office IT buildout | Network, devices, and connectivity lead time | Internet provisioning timelines outside anyone's control |
| Server or cloud migration | Its own inventory and cutover sequence | See the dedicated migration sequence |
Sequence
- 01
Scope it in writing
What is included, what success looks like, and what is explicitly out of scope, before work or pricing is discussed.
- 02
Estimate against the real environment
Not a generic package price; the estimate reflects your actual data volume, device count, or site conditions.
- 03
Sequence the work
A schedule that names dependencies outside anyone's control, like internet provisioning or a vendor's own timeline.
- 04
Hand it back to the recurring rhythm
Once accepted, the changed environment folds back into ordinary maintenance, support, and the operating model — not left as an orphaned one-off.
Project versus transition
Different questions, both needing documentation.
A project changes part of your environment on purpose. A provider transition changes who is responsible for the whole environment. Both need documentation and a clear handover, but they answer different questions.
- A project has a defined end date and acceptance criteria; ongoing service does not
- A project can run alongside an existing provider relationship; a transition replaces it
- A project's cost is estimated once; ongoing service is priced per user, per month
Before you sign an estimate
A serious estimate names its dependencies.
A serious estimate names what is included, what depends on someone outside the project (a vendor, a carrier, a landlord), and what happens if scope changes midway. See what shapes a number in general . Ask for that in writing before work begins, the same way you would for any other business commitment.
Next step
Turn your IT context into a clear scope.
A scope conversation covers your team, Microsoft 365, devices, vendors, and responsibilities to transfer. You leave with the scope questions that need answers—without sharing secrets.
Discuss your IT scope