Every managed services provider promises the same thing: immediate coverage, seamless transition, peace of mind starting day one. It’s an attractive pitch—who wants to wait 90 days to be fully covered?

In reality, immediate coverage is theater. Monitoring gets set up for the things you remember to tell the MSP about. Alerts get configured for the obvious stuff. And then six months later, a Lambda function someone deployed in 2019 and completely forgot about takes down production. The monitoring dashboards show green because while the MSP was aware the function existed, they weren’t aware it was critical.

We know this because we used to do it that way too.

We Used to Rush It

Early on, we’d get a new client signed and immediately start providing value. We would redirect their existing alerts into our systems, set up basic monitoring, and get our team responding to incidents within days. Everyone felt good about it.

The client was relieved they weren’t alone anymore. We were proud we could deliver fast. And then reality would slowly reveal itself: the backup job that was missing an important server, the security group that someone manually changed years ago to test something, the cron job that had been failing silently for three months.

We were monitoring what clients told us mattered. We had tooling that could see everything in the accounts, but without understanding criticality and dependencies, we’d focus on the obvious production systems.

Of course, we would ask questions and use our investigative skills to try to minimize the impact of that challenge. We came to there is no workaround for this problem. You simply can’t know what actually matters until you’ve inventoried everything, understood how it all connects, and identified what’s already broken but hasn’t exploded yet.

What Our 90 Days Gets You

Our onboarding now takes 90 days. Not because we’re slow, but because nothing short of a comprehensive review is sufficient. Production infrastructure that isn’t fully understood will eventually kill you.

Days 1-7: Critical coverage and complete discovery
We implement immediate monitoring for anything obviously critical. If you have a production API, we’re watching it. If you have databases serving customers, we’re monitoring them. You’re not blind during onboarding—but we’re also not pretending this first layer is complete.

Simultaneously, we start the real work: complete inventory of every AWS account, every resource, every integration. Not just the EC2 instances and RDS databases everyone remembers. The Lambda functions. The S3 buckets with lifecycle policies. The CloudFormation stacks that haven’t been touched in two years. The IAM roles that grant more access than anyone realizes. That one server that hasn’t been retired yet and everyone is afraid of touching.

We establish environment access for our entire team, enroll everything in our governance tooling, and set up the foundational monitoring infrastructure. Many MSPs rush through this because it’s not customer-facing. We’ve learned it’s the difference between having visibility and having the illusion of visibility.

Days 8-30: Determining what should exist
We run Well-Architected Reviews on all production workloads. We audit security logging—not just whether CloudTrail is enabled, but whether you’re capturing what you’d need during an incident and retaining it for as long as you need. We analyze backup coverage across every data repository. We scan for vulnerabilities and review patch management status.

Then we compare what exists against what should exist based on your risk tolerance, compliance requirements, and operational maturity. The gap between these two things is usually alarming.

We compile all of this into a Baseline Review—not a generic security scan report, but a prioritized roadmap of what needs to change. Some items are critical and get addressed immediately. Others become part of the ongoing work we fold into normal managed services operations.

Days 31-90: Building the system that works
Now we implement. We aggressively tag every resource so monitoring rules truly work. Datadog agents are installed on all servers and container pipelines are reconfigured so new deployments get monitored automatically. Service-specific monitors are configured based on how your workloads really behave, not generic thresholds that generate noise.

We implement the governance and security baseline: AWS Control Tower with a proper IAM Identity Center configuration, AWS Backup with appropriate retention, GuardDuty and Security Hub, VPC Flow Logs, ELB access logs. We call this basic blocking and tackling. Not sexy, but having this all in place keeps the day to day smooth and gives you everything you need to respond quickly when something goes wrong.

Most importantly, we document everything. Standard operating procedures for your specific environment. Runbooks for known issues. Access patterns. Dependency maps.

By day 90, we expect ourselves to know your infrastructure better than you do.

Some Prospects Walk Away

Not everyone wants this. Some hear “90 days” and disappear. They want monitoring in 48 hours. They want someone to take their existing alerts and respond to them faster. They want to feel like the problem is solved without actually solving the underlying problem.

Good. Those companies aren’t ready for managed services.

Some organizations are so attached to their current way of doing things that they’ll invent reasons why any improvement won’t work. “We can’t use AWS Backup because we need custom retention policies.” (AWS Backup supports custom retention policies.) “We can’t standardize tagging because our developers need flexibility.” (Your developers can have all the flexibility they want within a consistent tagging structure.)

When we see this pattern emerging, we’ll ask directly: do you want to improve this, or do you want to keep doing it your way and have us watch? Because if it’s the latter, you’re hiring an alert redistribution system, not a managed service provider.

We do our best work for clients who are ready to leave their problems behind. If you’re hiring an MSP because you want to keep doing things the way you’ve been doing them but with someone else on call, we’re not a fit. If you’re hiring an MSP because you want to stop worrying about infrastructure and focus on building your product, we’ll get you there—but you have to be willing to let us do it right.

Day 91

When something breaks, we will typically have a fix in place before you know it happened. Not because we got lucky, but because we instrumented the dependencies and understood the failure modes.

When you ask “should we do X,” we can answer intelligently. We know what’s running, how it’s configured, what will break if you change it, and what the second-order effects will be.

When your developer deploys something new, it automatically gets monitored, backed up, and secured according to your standards. They don’t need to configure CloudWatch alarms, backup policies, or security configurations. It just works.

When AWS announces a security issue, we know within minutes whether you’re affected and have already started mitigation. We don’t need to ask you what you’re running because we inventoried it all on day 15–and revisited it quarterly in our Quarterly Account Reviews.

Your infrastructure becomes the thing you don’t think about. Not because you’re ignoring it, but because it’s working. Your team builds features. Our team handles the production systems those features run on.

The Real Cost of Going Fast

MSPs selling rapid onboarding aren’t cheaper. They’re just spreading the cost out differently. You’ll pay for it later when the alert comes in at 2am and they escalate to you because they don’t understand your environment. You’ll pay for it when they implement monitoring that generates so much noise you start ignoring alerts. You’ll pay for it when the thing that breaks is something they could see but didn’t understand mattered.

Or you can pay for it up front. Ninety days of disciplined work to build complete coverage, real understanding, and actual safety.

Most infrastructure problems shouldn’t take 90 days to fix. But understanding infrastructure well enough to know which problems matter—that takes time. Rushing it just means you’re blind to the stuff that will hurt you.

We’ve been doing this for 20 years, starting with physical servers in data centers and transitioning through virtualization to cloud. The technology changes. The lesson doesn’t: if you don’t know what you’re managing, you’re not managing it.

Take the 90 days. Do it right. Or find an MSP who will tell you what you want to hear and hope nothing important breaks.