IT Projects & Migrations

Your IT projects done on time, on budget. So nobody notices.

The best compliment an IT project can get is that your team never realized it happened. That takes senior engineers who have done it before, a scope agreed upon before the first hour is billed, and a test run before anything touches production. Dave Cotton, our CTO, and his team run every project we take on, from the first scoping conversation to the handoff.

The expensive project is the one you do twice.

A failed migration is loud. Everyone knows the day the email stopped. But the projects that cost more are the quiet ones. The upgrade that finished on paper but left three people with a workaround they never mention. The cloud move that “worked” until the first audit asked where the data actually lives. The server replaced in March that nobody documented, so June’s outage took a full day to fix instead of an hour.

Those costs never show up on the project invoice. They get absorbed into payroll and patience, month after month, and they trace back to the same root: the work was handed to whoever was available instead of whoever had done it before.

A major technology change should not feel like a leap of faith.

A trusted team

With experience on your side, the plan works before you see it.

Every project we deliver is led by Dave Cotton, our Chief Technology Officer, and executed by senior engineers who work with infrastructure, cloud platforms, security, compliance, and business continuity every day. Your project is never treated as an entry-level support ticket, and it is never learning material.

That matters for a reason that has nothing to do with speed. Experienced engineers know which step breaks under which condition, so the risk is managed instead of discovered. That’s the difference between a cutover scheduled for Friday night and done by Saturday morning, and one that is still going on Monday.

Projects also arrive with context. Most of the work we take on comes out of a client’s technology roadmap, built and maintained by our founder-led Fractional CIO practice. By the time a project reaches Dave’s team, the business reasoning, the priorities, and the budget have already been worked out with leadership. The engineers are executing a decision, not guessing at one.

This is what a business-aligned MSP looks like applied to project work. The people who recommended the change, the people who build it, and the people who will support it afterward are the same team.

Dave Cotton
Chief Technology Officer

How a project runs

Every project follows these six steps, no matter the size.

Define the goal and the risk.

A senior engineer reviews your environment, objectives, affected users and systems, timeline, and compliance requirements. Then they identify the technical risks before anything starts. The questions are simple. What problem are we solving? What could go down? And what does done look like?

Scope before work begins.

Scope, timeline, investment, and responsibilities are agreed upon in writing. Clearly defined work is priced as a fixed fee. Work that depends on a vendor or has an open-ended scope is billed as time and materials, or a hybrid, and we tell you which before you sign. If something unexpected appears mid-project, we talk before we proceed. No surprise invoices.

Execute with senior engineers.

Work is milestone-driven and planned around your operations, including after-hours cutovers and next-day onsite support when a change touches how people work.

Keep everyone aligned.

You should never have to ask where the project stands. Receive milestone updates as they happen and a monthly summary when work crosses a calendar month. A single coordinator owns scheduling and communication while engineers own the technical work.

Test before go-live.

Wherever the project allows it, the new system is built and tested alongside your production environment before anyone depends on it. This is where migrations, compliance projects, and major upgrades are saved or lost.

Document, hand off, support.

Documentation is finished before the project completes and is written so the support team can maintain the environment from day one. You own it. When training is needed, we provide it. When the project is done, the same team that built it supports it under Managed IT.

What we take on

Projects we run

Cabling and audio-visual work that calls for a specialist is subcontracted to a partner we disclose and you approve in advance. Hardware and software procurement is transparent. You see every quote before purchase, and we recommend refurbished or new-old-stock where it is the right call, because stewardship of your budget is part of the job.
Project typeWhat it typically involves
Cloud migrationsMoving on-premise workloads to the cloud with data integrity, continuity, and control intact
Microsoft 365 and Google Workspace projectsTenant setup, migrations between platforms, and configuration done correctly the first time
Windows and server upgradesOperating system and server transitions planned around end-of-support dates, not after them
Network and infrastructure buildsFirewalls, switching, wireless, and segmentation designed, documented, and failover-tested
AI and automation projectsPractical automation of repetitive work, governed and privacy-aware.
Device imaging, deployment, and onboardingNew hardware configured, secured, and in users’ hands with minimal disruption
Office moves and reconfigurationsRelocating infrastructure with downtime measured in hours, not days
Project recoveryTaking over a stalled, delayed, or half-finished project and getting it done

What done looks like

After a well-run project you should be able to say all of this without checking:
Stability is the starting line. A project that only restores what you had is maintenance. The projects worth doing change what your business can do next.

Is Stepping Forward the right fit for my project?

We rarely take on project-only work for organizations that are not Managed IT clients, and we would rather say that here than on a discovery call. The team responsible for supporting your technology for the next five years should be the team that understands how it was designed, built, documented, and secured. When project work is disconnected from ongoing support, the usual results are inconsistent security, confusing handoffs, and a system nobody quite knows how to maintain. That is the quiet loss our business exists to prevent.

If you are evaluating a managed IT partner and want project capability as part of the decision, start with Managed IT Services.

Which do you need?

Managed IT vs. project-based IT

Managed IT

Managed IT is the ongoing partnership: monitoring, patching, user support, proactive maintenance, and strategy, covered by the monthly fee.

Vs.

IT Projects

IT Projects are planned, scoped, one-time initiatives with a defined outcome. They are quoted and approved separately before work begins. The roadmap from your strategic reviews is where most projects originate.

Your questions answered

Frequently asked questions about IT Projects

Yes. Professional Services is the industry term for scoped, one-time technology work that sits outside a managed services agreement. These include migrations, upgrades, infrastructure builds, and similar initiatives. You will see the term on our proposals and invoices. On this page we call it what it is: IT projects, delivered by senior engineers.
Senior engineers on our project team, led by Dave Cotton, our Chief Technology Officer, will complete your project. Projects are never assigned as entry-level support work. A dedicated coordinator manages scheduling, milestones, and communication so the engineers can stay focused on the technical work and you always know where things stand.
Clearly defined work is priced as a fixed fee so you know the investment before you approve it. Work that depends on third-party vendors or has a scope that cannot be fully defined up front is priced as time and materials, or a hybrid. We tell you which model applies, and why, before work begins. If the scope changes, we talk before we proceed.
Every project is planned to minimize downtime. Wherever the project allows, we build and test the new environment alongside production before go-live. Cutovers that require downtime are scheduled around your operations, often after hours, with next-day onsite support when the change affects how people work.
Rarely. The team that supports your technology long term should be the team that built and documented it. Disconnected project work tends to produce security inconsistencies and systems nobody knows how to maintain. If you are evaluating a managed IT partner and want project capability as part of the decision, we would rather have that conversation first.
Most projects originate in a client’s technology roadmap, built and maintained through our founder-led Fractional CIO practice. Strategic reviews surface aging hardware, end-of-support platforms, compliance gaps, and growth constraints while budget and options still exist. By the time a project reaches the engineering team, the business case and priority have already been decided with leadership.
Yes. Project recovery is one of the things we do. A senior engineer assesses what was built, what was documented, and what risk was introduced, then gives you a plain-language picture of what it takes to finish it properly. Sometimes that is a short engagement. Sometimes it means redoing work. Either way, you will know before you commit.

Bring us the project. We'll bring the plan.

If you are a current client, raise it at your next strategic review or message Matt now. If you are evaluating us, the fastest way to find out whether we are the right fit is a direct conversation with the person who leads the strategy.