What does MSP onboarding look like: what to expect in the first 90 days

Short answer: A real MSP onboarding takes 30 to 90 days and produces four concrete outputs – full environment documentation, deployed tooling on every device and identity, a security baseline with gaps closed or scheduled, and a mature helpdesk relationship backed by written runbooks. Servicing does not wait for onboarding to finish. The helpdesk is live and taking tickets from day 1 – what changes over the 90 days is how much context, tooling, and documentation is behind each ticket. Fast onboarding (1 to 2 weeks) is a red flag for environments larger than 15 to 20 users. Slow onboarding (over 120 days) without specific reasons usually means the MSP is under-resourced or the scope was wrong. What you want is a week-by-week plan with named deliverables, not a portal login and a phone number.

Onboarding is where the MSP relationship is built or broken. Everything you paid for – SLAs, proactive monitoring, security coverage, predictable support – depends on the MSP actually knowing your environment and having their tooling deployed on it. This article walks through what a good 90-day onboarding looks like, what the business needs to provide, what the milestones are, what good vs bad onboarding looks like day by day, and how to tell on day 30 whether you bought a real managed service or a ticketing portal with a logo on it.

MSP onboarding at a glance

Phase	Timeline	Primary outputs
Helpdesk live	Day 1	Ticket portal live, phone number live, users can open tickets, on-call staffed
Discovery and documentation	Week 1 to 2	Asset inventory, network diagrams, account map, access matrix
Tooling deployment	Week 2 to 4	RMM on every endpoint, EDR deployed, MDM enrolled, backup configured, monitoring live
Security baseline assessment	Week 3 to 6	Gap analysis, MFA enforcement, conditional access, admin separation, patch posture
Helpdesk maturation	Week 4 to 8	Runbook handoff to service desk, documented context in every ticket, steady-state metrics stabilizing
Runbook and handoff	Week 8 to 12	Documented runbooks, incident response plan, first QBR scheduled, onboarding close

Servicing and onboarding run in parallel, not in sequence. The helpdesk is staffed and taking tickets on day 1 – users can report broken laptops, locked accounts, and email problems from the kickoff forward. What changes across the 90 days is the depth behind each ticket: by week 2 the engineer answering has the asset inventory, by week 4 they have RMM visibility and remote access, by week 6 the security baseline is in effect, and by week 8 there is a written runbook for your environment. Early tickets work; they just take longer and depend more on the user to supply context.

The phase timelines also overlap on purpose. A serious MSP does not wait for discovery to finish before starting tooling deployment, and does not wait for tooling deployment to finish before touching security. Parallelism is how 90 days stays 90 days instead of 180.

What the business needs to provide

Onboarding is bidirectional. The MSP cannot discover, deploy, and secure your environment if they do not have access and answers. Everything below should be assembled before day 1 or collected in the first two weeks.

Administrative access. Global admin to Microsoft 365 or Google Workspace. Domain admin to any on-prem Active Directory. Admin access to the firewall, switches, wireless controller, and any network appliances. Root or administrator access to any servers. If you do not know who has these credentials, that is itself a finding the MSP will document.

Identity and account inventory. A list of users, their roles, their email addresses, and any shared mailboxes or service accounts. Former employee accounts that may still be active. Contractor accounts. Anything with licenses attached.

Physical and network inventory. A rough count of laptops, desktops, printers, servers, firewalls, switches, access points, and any specialty hardware. Which locations have which equipment. Which users work from which locations. If a structured network assessment has ever been done, the existing inventory and topology diagrams short-cut a large part of this phase.

Line-of-business applications. What software actually runs the business – the EMR, the legal practice management system, the CAD workstations, the accounting suite. Who the vendors are. Who pays the vendor bills. Whether there are any vendor support contracts or implementation partners the MSP will need to coordinate with.

Existing documentation, if any. Network diagrams, password vaults, runbooks, vendor contacts, compliance documentation. If the previous IT arrangement was a single internal person or a break-fix provider, expect this to be sparse or missing – which is itself one of the things the MSP will fix.

A point person. One person on your side who can answer questions, approve decisions, and unblock access. Usually the owner, CFO, office manager, or internal IT person. Without this, onboarding stalls. A good MSP will make this explicit in the onboarding plan.

If you are switching from another MSP, you also need the exit checklist from that provider – documentation, credentials, tooling license ownership, data exports. This is where outgoing MSPs commonly get uncooperative. Start that conversation early, in parallel with the new MSP’s onboarding kickoff.

Phase 1: discovery and documentation (week 1 to 2)

The first two weeks are the MSP learning your environment. Nothing you bought works yet. No tooling is deployed, no SLAs are in effect for proactive work, and the helpdesk is not yet the primary support channel. What is happening is an engineering team is building the operational picture they will manage for the next several years.

Kickoff meeting. A real kickoff covers the onboarding plan week by week, names the people on the MSP side (technical lead, account manager, onboarding project manager), names the people on your side, sets the cadence for status updates, and clarifies what is out of scope. It should end with a written onboarding plan, not just a shared calendar invite.

Environment discovery. The MSP catalogs everything – every user, every device, every server, every network device, every SaaS subscription, every line-of-business app, every shared account, every vendor relationship. This is tedious and takes most of the first two weeks. It is also the foundation for everything that comes after.

Documentation production. Discovery outputs are written up into documentation that lives in the MSP’s documentation platform (IT Glue, Hudu, or similar) and is available to every engineer who will ever touch your environment. Network diagrams, asset registers, account matrices, application dependency maps. This is a deliverable you should review.

Initial findings report. By end of week 2, the MSP should produce a written findings report covering: what is in the environment, what is immediately concerning (expired warranties, unpatched servers, shared admin credentials, no MFA on M365, no backup on critical systems), and what the remediation plan is. You should not have to ask for this.

Good onboarding this phase looks like: the MSP asks questions that show they are paying attention. They find things you did not know about (the service account still tied to a former employee, the firewall with firmware from 2019, the file share that has not been accessed in 18 months). They document proactively. The findings report is specific and prioritized.

Bad onboarding this phase looks like: you send over credentials and hear nothing for a week. The kickoff is a rushed 30-minute call with no written plan. Discovery is done by a ticketing system asking you to fill in forms. The findings report is a boilerplate template with your name on it.

Phase 2: tooling deployment (week 2 to 4)

Tooling is what makes managed IT different from reactive IT. Until the MSP’s stack is on every device and identity in your environment, they cannot see what is happening, cannot patch proactively, cannot detect threats, cannot back up what needs backing up, and cannot respond fast to incidents. The proactive half of the value proposition starts here.

Remote monitoring and management (RMM). The RMM agent goes on every workstation, laptop, and server. It collects health data, manages patches, enables remote access for support, and feeds the MSP’s monitoring and alerting. This is usually the first agent deployed because everything else depends on it. Expect the deployment to be automated – Intune push for M365 environments, Group Policy or an onboarding script for on-prem environments. (For what RMM actually does, what MSPs can and cannot see with it, and what to ask about RMM operations, see the primer.)

Endpoint detection and response (EDR). EDR replaces traditional antivirus with behavioral threat detection. The agent goes on every endpoint, including servers. Initial deployment triggers some noise as the MSP tunes policies and investigates benign behaviors flagged on first sight. For what EDR actually does and why unmanaged EDR under-delivers, see the primer on EDR.

Mobile device management (MDM). Intune for M365 environments, Jamf or Kandji for Apple fleets, Workspace ONE for mixed. The deployment itself is sometimes scoped as a separate project if you do not yet have MDM – if you do, the MSP takes over operation during onboarding.

Email and identity security. MFA enforcement on every account. Conditional access policies scoped to your environment. Phishing-resistant authentication for admin accounts. Email security platform (Mimecast, Proofpoint, Microsoft Defender for Office) tuned to your domain and inbound mail patterns. If the MSP is layering a security platform on top of existing M365 licensing, expect a few days of tuning noise.

Backup. Microsoft 365 backup covering Exchange, OneDrive, SharePoint, and Teams. On-prem backup coverage for any servers, with offsite or immutable-storage replication. RTO and RPO targets written down. Backup restores tested in the first 30 days, not left as a theoretical.

Monitoring and alerting. The RMM and security tooling feed into the MSP’s NOC and SOC. Alerts are tuned to reduce noise. On-call rotations are wired up to your environment. By end of phase 2, if a server goes down at 2am, somebody gets paged.

Good onboarding this phase looks like: agent deployment is almost fully automated and finishes within days, not weeks. The MSP shows you a dashboard by end of week 4 with every device visible, every identity covered, and backup jobs running green. Tooling is included in the fee you were quoted, not billed as a surprise project. Early noise from new tooling is acknowledged and managed.

Bad onboarding this phase looks like: agents rolling out one device at a time over 6 to 8 weeks because there is no automation. Deployment gaps – 60 out of 80 devices covered, the remaining 20 forgotten. Tooling that was promised in the proposal turning into a “phase 2 project” with a separate quote. No visibility dashboard, just a ticketing system. For the deeper version of what to ask about tooling before signing, see how to choose a managed IT service provider.

Phase 3: security baseline assessment (week 3 to 6)

This phase overlaps tooling deployment because some of what the MSP is doing – MFA enforcement, conditional access, EDR policy tuning – is itself security baseline work. The deliverable is a written gap analysis: what was there when the MSP took over, what is there now, and what is scheduled for remediation.

What a baseline assessment covers:

• Identity hygiene. MFA coverage, admin account separation, dormant accounts, shared credentials, password policy, privileged access management. Gaps here are usually the highest-priority fixes.
• Endpoint posture. Patch levels, disk encryption, local admin rights, EDR deployment completeness, antivirus exclusions, removable media policy.
• Network posture. Firewall rules (especially any inbound exposures), firmware currency, wireless security, VLAN segmentation, VPN configuration, remote access methods. If the office still runs on a consumer router or mesh kit, that almost always becomes a flagged remediation item – business WiFi vs consumer WiFi: why it matters for your office explains why.
• Email posture. SPF, DKIM, DMARC records. Mail flow rules. Inbound filtering effectiveness. Phishing training history.
• Data protection. Backup coverage and tested recovery, data classification, sensitive data locations, M365 retention policies, ransomware resilience.
• Compliance-specific gaps. If you are in a regulated industry, gaps against HIPAA, SOC 2, PCI, or CMMC requirements.

Written gap analysis. By end of week 6, you should have a written document listing every finding, its severity, its remediation plan, and its target close date. Easy wins (MFA enforcement, missing DMARC records) are typically closed during the assessment itself. Larger remediation (firewall replacement, AD cleanup, M365 tenant hardening) is scoped as follow-on work with clear timelines.

What “close” means. The MSP should not leave findings open indefinitely. Either a finding is closed (fix deployed, verified), accepted by the client (documented risk acceptance with sign-off), or scheduled with a specific target date. Open-ended “we will get to it” is a failure of operational discipline.

Good onboarding this phase looks like: the gap analysis is specific, prioritized, and honest. The MSP is not selling the assessment as “everything is fine, just renew our fee every year.” They found things that are actually wrong and have a plan to fix them. Critical findings are closed before onboarding ends.

Bad onboarding this phase looks like: a boilerplate assessment with generic findings that could apply to any small business. Everything is “medium priority” because nothing was actually investigated. Findings are listed but have no remediation plan attached. Critical gaps (no MFA, no backup, exposed RDP) are flagged but left open past onboarding.

Phase 4: helpdesk from day 1 to maturation (week 1 to 8)

The helpdesk does not wait for onboarding to finish. A good MSP turns on the ticket portal, the phone number, and the on-call rotation on day 1 so users can get help from the moment the kickoff ends. What matures over the first 8 weeks is not whether support exists – it is how much context, tooling, and documentation sits behind each ticket.

Day 1: helpdesk live. Users have the ticket portal URL, the phone number, and a simple reference card explaining how to open a ticket, what the priority tiers mean, and how to escalate. On-call is staffed. If a laptop dies on day 2, somebody is answering the phone. Early tickets lean more heavily on the user to supply context (which app is broken, which server it lives on) because the engineer does not yet have full environment documentation. That is normal and expected – it just means early tickets take longer and involve more back-and-forth.

Week 1 to 2: early tickets feed discovery. Every ticket in the first two weeks is also a discovery event. The engineer answering the call learns your users, your applications, your quirks, and your business rhythm. Good MSPs route these tickets through the onboarding team or keep tight communication between onboarding engineers and the service desk so context is captured in documentation immediately, not lost after the ticket closes.

Week 2 to 4: tooling makes tickets faster. As RMM, EDR, and MDM deploy, the helpdesk gets dramatically more effective. Instead of asking “what is your laptop doing,” the engineer can see CPU, memory, disk, installed software, patch state, and recent events. Remote access lets them take over the session instead of walking the user through clicks. Ticket resolution times drop materially once tooling is on every endpoint.

Week 4 to 8: helpdesk maturation. Runbooks specific to your environment are written and referenced in tickets. The service desk engineers (not just the onboarding team) have full environment context. Escalation paths are documented – tier 2 engineer, network engineer, security team, project services, account manager – and the user knows how to escalate without guessing. Ticket metrics start to stabilize into what steady-state performance looks like.

Documentation handoff to the service desk. The engineers who did discovery and deployment pass institutional knowledge to the engineers who will answer tickets long-term. This handoff is where a lot of MSPs fail silently – the onboarding engineers knew everything, the steady-state engineers know nothing, and users end up re-explaining the same context every ticket. Good MSPs close this gap with documented runbooks in a platform every engineer has access to, and by keeping the onboarding engineer involved in the first month of tickets as a warm handoff rather than a cliff.

User communication. Day 1 is a kickoff email or short lunch-and-learn introducing the helpdesk, the portal, the phone number, the priority tiers, and what to expect in the first 90 days. Users should know that the first couple of weeks may feel a bit slower because the MSP is learning the environment, and that they can help by providing context on tickets. A quick reference card on the desktop or intranet reduces the “how do I get help” question.

After-hours coverage. The on-call rotation for P1 incidents is active from day 1 for any incident the MSP can handle with the information available. As tooling deploys through weeks 2 to 4, after-hours capability gets sharper – alerts fire automatically, the on-call engineer can remote in instead of talking a user through it, and EDR/SOC monitoring starts catching incidents before users do.

Good onboarding in this phase looks like: users have a working helpdesk from day 1, early tickets close even without perfect tooling visibility, and by week 4 tickets feel fast and contextual. Service desk engineers reference runbooks specific to your environment. Users are not being told “we can’t help you with that yet.”

Bad onboarding in this phase looks like: the helpdesk is not actually live for the first few weeks (“we’ll turn it on when onboarding is done”), so users have no support during the period their environment is most fragile. Or the helpdesk is nominally live but nobody picks up the phone, tickets sit unassigned, and users go back to calling the old internal IT person or former MSP. Or every ticket in weeks 1 to 4 turns into a rediscovery exercise because no one is capturing context in documentation. Or after-hours coverage is undefined until week 8.

Phase 5: runbook, handoff, and first QBR (week 8 to 12)

The last phase is about closing onboarding as a project and transitioning to steady-state managed services. Specific deliverables close out and the account manager takes over from the onboarding project manager.

Runbook production. Written runbooks for the things the MSP will do routinely – monthly patching, backup verification, quarterly vulnerability scans, user onboarding, user offboarding, disaster recovery procedures, security incident response. These live in the documentation platform and are the operational manual for your environment.

Incident response plan. A documented IR plan specific to your environment – what to do in a ransomware scenario, a business email compromise, a lost laptop, a departing employee who becomes a concern. Named roles, named contacts, named decisions. This is distinct from the generic IR template; it should reference your actual systems and your actual business.

User onboarding/offboarding process. Written checklists for adding and removing users. License provisioning, security group membership, MFA enrollment, equipment assignment, access review, offboarding device wipe, license reclaim, access revocation. The MSP runs this on every HR transition from now on, without needing to be told. (The offboarding process itself is a distinct workflow worth understanding.)

Business review scheduled. The first quarterly business review (QBR) is scheduled for month 4 or month 5, usually with the account manager present. QBR agenda typically covers: SLA performance against commitments, ticket volume and trends, security posture changes, completed and upcoming projects, budget and license utilization, strategic IT planning for the next quarter.

Onboarding formal close. The onboarding project manager hands the relationship to the account manager. Any open onboarding findings that did not make it into the first 90 days are explicitly rolled into steady-state work with their own timelines. The onboarding project is closed in writing, with a final report.

Good onboarding this phase looks like: the runbooks are written and specific, the IR plan references your actual environment, the first QBR is on the calendar, and you know who your account manager is. Open items are tracked, not quietly dropped.

Bad onboarding this phase looks like: onboarding “ends” because the clock ran out, not because deliverables are complete. No runbooks, no IR plan, no QBR scheduled. The onboarding engineer disappears. The account manager is hard to reach. Months 4 and 5 feel like a different company than months 1 and 2.

How long should MSP onboarding actually take

Scope drives duration. The honest answer is “it depends on how complex your environment is.”

Environment size and complexity	Typical onboarding duration
5 to 15 users, cloud-native, no servers, single site	30 to 45 days
15 to 50 users, M365 or Google Workspace, minimal on-prem	45 to 60 days
50 to 150 users, some on-prem infrastructure, multiple sites	60 to 90 days
150 to 250+ users, hybrid environment, regulated industry	90 to 120 days
Regulated with pre-existing compliance debt	120+ days with a phased remediation plan

Faster than the table above is usually a red flag. An MSP onboarding a 100-user environment in two weeks either skipped real discovery, skipped the security baseline, or both. A later surprise – “we found something we did not know about” or “that was out of scope” – is almost guaranteed.

Slower than the table above is sometimes a red flag, but not always. Legitimate reasons for extended onboarding: a regulated industry with significant compliance work, a switch from an uncooperative outgoing MSP where documentation is missing, a large remediation project that is intentionally phased over the first 6 months. In those cases the timeline should be written down and explained.

A good MSP will tell you on day 1 how long they think onboarding will take, and what the dependencies are. That estimate should survive first contact with your environment, or be revised in writing with a specific reason.

What a written onboarding plan should include

Before signing, ask to see the onboarding plan template. Review it again when your specific plan is produced in week 1. It should have:

• Week-by-week milestones. Discovery complete by when, agent deployment complete by when, security baseline complete by when, helpdesk live by when, runbooks complete by when.
• Named deliverables. The asset inventory, the network diagram, the findings report, the gap analysis, the runbooks, the IR plan, the first QBR. Each one has a target date and an owner.
• Named roles. The onboarding project manager, the technical lead, the account manager. Their contact information and their role.
• Your responsibilities. What access you provide when, what documentation you hand over, who your point person is, what decisions need your sign-off.
• A status cadence. Weekly status updates during onboarding. A mid-point review (day 45 or so). A closing report at 90 days.
• An escalation path specific to onboarding. If something is stuck, who do you call.

If the onboarding plan is a single paragraph in the contract, that is not enough. Ask for the detailed version. Any MSP worth onboarding you has one.

Red flags in MSP onboarding

Signs the onboarding is not going well, usually visible by day 30:

You still do not have a written onboarding plan. If you have not seen a week-by-week schedule with named deliverables by end of week 2, the MSP is winging it.

Tooling deployment is stalled. Agents are supposed to be on every endpoint by end of week 4. If day 30 arrives and half your devices have no RMM or EDR, the MSP is either under-resourced or does not have automated deployment.

The findings report is boilerplate. If the gap analysis reads like it could apply to any business, the MSP did not actually investigate your environment.

Discovery is happening via forms, not conversations. Real onboarding involves an engineer getting on a call and asking “what does this Windows 2012 server do” and listening to the answer. Sending you a 40-question spreadsheet to fill out is not discovery.

The onboarding engineer is not reachable. You open a ticket for a week-old question and a different engineer responds with no context. The onboarding handoff inside the MSP itself is already broken.

Phase 2 keeps slipping without explanation. Timeline slippage with documented reasons (dependency on your DNS provider, waiting on firewall replacement, scope expanded after discovery) is normal. Timeline slippage with no explanation is a capacity problem on the MSP side.

Major findings have no remediation plan. The baseline assessment flagged no MFA on admin accounts and there is no specific plan to close it by end of onboarding. That is an MSP treating the assessment as a report, not a remediation.

The tooling in the proposal is “coming in phase 2.” Every tool you paid for in the per-user fee should be deployed during onboarding. If MDM or EDR or email security is deferred to “phase 2” and then “phase 2” gets a separate quote, you are being upsold during onboarding. (The MSA guide covers what should be in scope vs what is legitimately a project – if tooling deployment is scoped as a project, that should have been in the contract.)

How good onboarding differs from bad onboarding, in one table

Signal	Good onboarding	Bad onboarding
Kickoff	Written plan with weekly milestones	30-minute call, no follow-up plan
Discovery	Conversations with your people	Spreadsheets you fill out alone
Documentation	Real artifacts in a doc platform	Nothing, or “we’ll document later”
Findings report	Specific, prioritized, remediation-attached	Boilerplate, generic, no plan
Tooling deployment	Automated, done by week 4	Manual, dragged out to week 10+
Security baseline	Gap analysis with closures in 30 days	Flagged but open past onboarding
Helpdesk	Live from day 1, matures as tooling and docs come online	Stood up late, or nominally live but unstaffed
Runbooks	Written, specific to your environment	Never produced, or template copy-paste
Communication	Weekly status, named PM, mid-point check-in	Silence between milestones
Close-out	Written completion report and scheduled QBR	Fades out, no explicit close

How onboarding connects to what you actually pay for

Reactive helpdesk support is live from day 1 – but proactive managed IT scales up as onboarding progresses. SLAs on proactive work (patching cadence, backup verification, monitoring response) depend on tooling being everywhere and visibility being complete. Proactive patching does not happen until the RMM agent is on every endpoint. Security monitoring does not happen until EDR is deployed and tuned. The helpdesk resolves tickets from the start, but it resolves them dramatically faster once runbooks exist and tooling is in place.

This is why onboarding matters more than almost any other part of the engagement. A great MSP with a broken onboarding is a great MSP whose proactive value you cannot realize yet. A mediocre MSP with a tight onboarding is at least a functioning operation by day 90.

When you are comparing MSPs, ask specifically: “Walk me through onboarding week by week. What are the deliverables? What is your median onboarding duration for similar-sized clients? Can I talk to a reference client about their onboarding experience?” The answers tell you more about operational maturity than any other part of the sales conversation. (For the full question list to run through before signing, see how to choose a managed IT service provider.)

Switching MSPs: onboarding with an incumbent in the room

If you are switching rather than buying your first MSP, onboarding has an extra dimension – the outgoing MSP. They control documentation, credentials, and sometimes licensing. They may or may not cooperate with the transition.

Things to do in parallel with the new MSP’s onboarding:

• Get the exit deliverables from the incumbent in writing. Asset inventory, network diagrams, password vaults, vendor contacts, licensing ownership (are the Microsoft 365 licenses on your tenant or theirs?), tooling licenses (who owns the Veeam subscription?).
• Confirm you own your domains, DNS, and M365 tenant. These should be registered to your organization, not the MSP. If they are not, fixing that is the first onboarding task.
• Run the two MSPs in parallel for 2 to 4 weeks. The incoming MSP does discovery and deployment with the outgoing MSP still running steady-state support. The cutover to the new helpdesk happens after deployment is verified.
• Treat documentation handoff as a contract obligation, not a favor. The outgoing MSP should be providing exports, admin credentials, and context transfer. If they stall, escalate in writing.

A good new MSP will have a standard playbook for switching scenarios because it is a common pattern. Ask about it before signing. The full switching playbook – pre-notice audit, parallel running, and how to recover from a bad exit – is covered here.

How Sequentur handles onboarding

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. Our typical onboarding runs 60 to 90 days depending on environment complexity, with regulated or compliance-heavy engagements sometimes extending to 120 days when there is documented remediation work.

We produce a written week-by-week onboarding plan before work starts, assign a named onboarding project manager plus a technical lead, and run weekly status updates through closure. Tooling deployment is automated where it can be – RMM, EDR, and M365 security baselines roll out in days, not weeks – and we deploy the full tooling stack that was in the proposal, not a reduced “phase 1” subset.

The security baseline assessment is written, specific, and prioritized. Critical findings close during onboarding. Non-critical remediation is either closed, explicitly accepted by you in writing, or scheduled into steady-state work with a target date.

Runbooks, incident response plans, and user on/offboarding checklists are produced during onboarding and live in documentation every engineer on your account has access to. The first QBR is on the calendar before onboarding closes. When onboarding ends, you have a written close-out report that says what we did, what is open, and when the open items will close.

If you are evaluating MSPs and want to see what an onboarding plan actually looks like before you commit, schedule a call. We will walk you through the standard 90-day plan, show you a sample findings report from a similar-sized environment (client names redacted), and answer specific questions about how we handle your industry and your current infrastructure. If your environment is small and simple enough that a faster onboarding is realistic, we will tell you that too.