Transparent process
You see "IT implementation".
We open every stage.
No black boxes. Specific steps, realistic timelines, a list of what you get - and what happens after go-live, when most vendors disappear.
Schedule overview - standard ManageEngine SDP implementation (50-600 users)
Where this process comes from
This process
was not born
in a classroom.
For 10 years we managed IT infrastructure in environments where downtime had consequences - and not only financial ones. Clinics, pharmacies, schools, public institutions. SLA contracts with real penalties for every hour of unavailability. A pharmacy system outage at 2 AM is not "low priority". When you run infrastructure like that for a decade, you design implementation processes differently.
Rollback plan before we press "start"
In medical environments, go-live without a rollback procedure is a mistake you pay for. That is why the rollback plan is ready before go-live - not "just in case".
Monitoring configured before handover - not after
We have seen 400 alerts a day that no one read. Alert fatigue equals no monitoring. That is why monitoring and alerts are an acceptance requirement, not a "to be done later" option.
Living documentation throughout the maintenance period
Configuration as documented on go-live day becomes fiction after 2 years. That is why every change is documented as it happens.
Field signals - without client names
Pharmacy, 5 hours of downtime. Backup "was configured". Restore did not work - no one had verified it in 8 months. We discovered it during a pre-implementation audit. Without the audit, the discovery would have happened during the outage.
Medical environment, single point of failure. The entire clinic network depended on one core switch. Redundancy "planned for 2 years". An expensive lesson - a server replaced in emergency mode over the weekend.
Takeover after a previous partner. Documentation: one Word file dated 3 years earlier. One admin who "knew everything" - had left 4 months earlier. The environment was working, but no one knew why or for how long.
School, monitoring configured. 400+ alerts per day. No one had reacted for a week - "there are always that many". The real outage came silently, with no alert. Finding it took 3h.
ITSM implementation, 8 months after go-live. The vendor signed off, got paid. The client discovered that 40% of users were still submitting tickets by email - "because it is faster". Adoption: 58%. No one measured it, no one intervened.
Stage by stage
What we do - and when.
No surprises.
Every stage has a clear goal, a list of activities and something you receive from us at the end. If something requires a decision on your side, we say so directly, with advance notice.
01
Discovery - understanding the problem before proposing a solution
First we listen. Workshops with your IT team and business owners, review of current infrastructure, conversations with end users. At this stage our only goal is to understand what is actually broken - not what is written in the RFP.
What we do
- Discovery workshops (1 day) with the IT lead and business owners
- Review of current tools and processes
- Conversations with end users (minimum 3 roles)
- Inventory of integrations and system dependencies
- Assessment of IT maturity and organizational readiness for change
What you do
- Provide access to the IT lead and 2-3 business owners (1 day)
- Share documentation of current systems (if it exists)
- Point out 3-5 pain points from your perspective
- Enable conversations with selected end users
Risks at this stage
- Incomplete client-side knowledge of own processes - we resolve this through workshops, not surveys
- Discrepancy between what IT says and what the business says - we document both perspectives
- No single person with decision-making authority - we escalate before the start, not midway
Discovery Report
Map of problems and processes
List of integrations to investigate
Organizational readiness assessment
Project scope
What you receive: A written current-state report - not marketing slides, but a document on which you can decide whether the scope of the implementation is right or whether it needs to be adjusted. The scope approved at this stage is the basis of the contract.
02
Analysis and architecture - a design you can challenge
Based on discovery we design the solution architecture. Every decision is justified - cloud vs. on-premise, licenses, integrations, deployment model. You receive a document you can take to your IT architect and ask "does this make sense".
What we do
- System architecture design (ADR - Architecture Decision Record)
- Deployment model selection: cloud SaaS / on-premise / hybrid
- Design of integrations with AD/LDAP, network infrastructure, external systems
- Licensing plan (modules, number of agents, SLA thresholds)
- CMDB structure and ticket category design
- Architecture review with your team - Q&A, corrections
What you do
- Review of the ADR document (2-3h of IT lead time)
- Cloud vs. on-premise decision (if not in scope already)
- Confirmation of the licensing plan
- Acceptance of the CMDB structure and ticket categories
- Indicate the maintenance window for installation
Risks at this stage
- Discovery of new technical dependencies - handled through an ADR revision, not a production surprise
- Change of cloud/on-prem decision after discovery - possible, but requires scope revision
- Unclear security/compliance requirements - we verify with your security team
Architecture Decision Record (ADR)
Architecture diagram
Licensing plan
Integration design
CMDB design
Project schedule (Gantt)
What you receive: A design document that remains yours regardless of how the project unfolds. If you choose another partner, you have a ready architecture blueprint. If the project starts, the ADR is the technical agreement between us and your team.
03
Implementation - configuration, integrations, data migration
Installation, configuration aligned with the ADR, integrations with the existing ecosystem, migration of historical data (if in scope). Weekly reports - what is done, what comes next, whether anything is blocked. We quote out-of-scope changes within 48h and never deliver them quietly.
What we do
- Installation and baseline environment configuration
- Configuration of roles, permissions, workflows and SLA escalations
- Integration with Active Directory / Azure AD
- Integrations with external systems (ERP, monitoring, email)
- Migration of historical data (tickets, CMDB, KB) - if in scope
- Configuration of operational monitoring and alerts
- Weekly status reports with progress
What you do
- Administrator access to environments (AD, network, servers)
- Weekly configuration review and approval (1-2h of IT lead time)
- Decisions on scope changes (with 48h notice from us)
- Provide migration data in the agreed format
- Assign 1-2 power users for pre-testing
Risks at this stage
- Inconsistent migration data - we audit data before migration, we do not bet on "it will work out"
- Mid-sprint scope changes - every change via a formal change request
- Dependency on external systems (API unavailable, legacy) - identified in discovery, with planned workarounds
Configured production environment
Integration test report
Configuration documentation
Migrated (historical) data
Weekly status reports
What you receive every week: A short report (max. 1 page) - what was done, what is on the table, what decisions are needed on your side and whether the schedule holds. If something is delayed, we are the first to say so - we do not wait for you to ask.
04
Tests and training - the system verified by people, not just tools
User Acceptance Testing with your users - not developer tests. Test scenarios based on real cases from your organization. Training for administrators and end users. And one element most vendors skip: rehearsing an emergency scenario before go-live.
What we do
- Prepare UAT test scenarios (based on your processes)
- Support UAT with your team (verification, bug fixes)
- Administrator training (4-6h, recorded)
- End-user training (2h, script + recording)
- Incident scenario rehearsal - "what we do when X goes down"
- Configuration of production monitoring and alerts
What you do
- Provide 3-5 users for UAT (2-4h each)
- Collect UAT feedback and pass it to us with priority
- Take part in the incident rehearsal (IT lead + 1 admin)
- Communicate go-live to the organization (we help with the content)
Risks at this stage
- Users unavailable for UAT - we plan UAT with 2 weeks of lead time
- Critical bug discovered in UAT - we prioritize the bugfix, we do not postpone it to "after go-live"
- Low attendance at training - we record everything, online materials remain available after training
UAT protocol with results
Admin training recordings
End-user training recordings
Incident playbook (v1)
Go-live communication plan
Go-live readiness checklist
Incident rehearsal: We simulate one typical production incident - e.g. server unavailability, AD integration error - and walk through the procedure together with your team. The goal is that the first real outage is not the first lesson in response.
05
Go-live - we switch, monitor, correct
Go-live is not the end of the project - it is the start of operations. We switch in a maintenance window (typically evening or weekend), we stay on hand for 48h, and for the next 4 weeks in heightened-availability mode. The rollback plan is ready before we press "start".
What we do
- Final verification of the readiness checklist (the day before)
- Switch to production in the agreed maintenance window
- Monitoring for the first 48h - we are available
- Configuration corrections based on first production data
- Communication to users (with HR and communications teams)
- Activation of monitoring and operational dashboards
What you do
- Approve the go-live date and window at least 7 days in advance
- Ensure IT lead availability for the first 48h after go-live
- Communicate the change to users (materials provided by us)
- Collect feedback from the first days of production
Risks at this stage
- Unexpected production issue - rollback plan ready, executable in max. 2h
- Low adoption in the first days - this is normal, we intervene with communication and micro-training
- External integration issue after go-live - escalation to the vendor with our support
Go-live protocol
First 48h report
Active production monitoring
Rollback plan (in case of revert)
Rollback plan: Before we activate production, we have a ready rollback procedure - environment snapshot, list of steps, execution time. We do not bet on everything going well. We prepare for the scenario where it does not.
06
Hypercare and support - we stay where others disappear
Hypercare is not "helpdesk for 2 weeks". It is active oversight: we monitor system KPIs, we react to signals before they become incidents, we add training where gaps appear. After hypercare: maintenance contract or hours-based support package - your decision, without pressure.
What we do (hypercare)
- Monitor system KPIs: response time, adoption rate, SLA breaches
- Weekly status call with the IT lead
- Micro-corrections to configuration based on first data
- Additional training for users where gaps appear
- Verification that monitoring and alerts work correctly
- Final report from the first 4 weeks of operations
What you do
- Collect and forward user feedback every week
- Take part in weekly calls (30 min)
- Decide on the post-hypercare support model (without pressure)
- Update internal process documentation
Risks at this stage
- Low adoption - active intervention in the first 2 weeks is decisive
- Falling back into old habits (old system "on the side") - we identify and address this immediately
- Key admin leaving after go-live - living documentation and training recordings protect against this scenario
Hypercare report (4 weeks)
Living documentation (final)
Operational runbook
Incident playbook (final)
Maintenance plan and roadmap
After hypercare: We do not leave you with nothing. You have a choice: a maintenance contract (hourly SLA), prepaid support hour packages (no monthly commitments) or ad-hoc - call when you need us, we quote each engagement. None of these options is required to close the project.
Critical stage - this is where the implementation succeeds or fails
What happens after go-live.
This matters more than the implementation itself.
Most vendors optimize for project sign-off. We optimize for the system still working a year from now. These two goals are different - and they translate into different decisions throughout the project.
Stabilization and configuration correction
The first production data reveals what tests do not show. Ticket categorization does not fit reality? We fix it. SLAs too strict for one user group? We calibrate. Micro-corrections at this stage cost hours - the same changes 3 months later cost days.
Adoption rate - the most important metric
We measure what percentage of tickets goes through the system and what still goes by email. We identify low-adoption teams and address it specifically - a short 30-minute training session, a video, a conversation with a manager. Ignoring adoption in the first 4 weeks is the most common post-go-live mistake.
Operational report + 6-month plan
Summary: what worked, what needed correction, what metrics were reached vs. assumed. And a recommendation for the next 6 months: which modules to add, where to optimize, which integrations make sense. Not to sell - to give you a roadmap you can accept or reject.
Living documentation - a knowledge system that lives
Configuration evolves - documentation has to keep up. Every month we update the ADR with changes that went live. After 3 months every change is documented.
SLA verification and workflow optimization
After 3 months of data it becomes clear which SLAs are realistic and which are declarative. Which workflows are used and which are bypassed. We review and recommend concrete changes. An ITSM system configured "on paper" delivers no value.
Incident response - before you call us
Every implementation ends with an incident playbook: what you do yourself in the first 15 minutes of each common failure, when you escalate to us and how (phone / ticket / email depending on severity). The first production outage should not be the first lesson in response.
Risk management
Things that break.
And how we handle them.
Every project has risks. The difference between a good and a bad vendor is not "we have no risks" - it is the transparency about which risks we identify and how they are managed.
Risk - and what really happens
Scope creep - the project grows out of control
The client adds requirements "while we are at it". The vendor delivers without a quote - afraid to refuse. After 4 months the project is twice as expensive as in the proposal. The board asks why IT costs that much and delivers so little. The vendor disappears.
How we handle this
Formal change request - every change in writing within 48h
Minor changes (max 2h of work) we deliver within the project, with no formalities. Every significant change: a written impact assessment on time and budget within 48h, before any work starts. There is no "invoice surprise".
Risk - and what really happens
Key person leaving mid-project
The IT lead on the client side leaves in week 6. The replacement has no context. Decisions from discovery are "somewhere in the emails". The project rolls back 3 weeks. Or worse - it goes in the wrong direction, because no one remembers why something was planned this way.
How we handle this
ADR + weekly reports = project memory independent of people
The entire decision context lives in the ADR and weekly reports. A new person on the client side or our side can get up to speed in 2h - without interrogating their predecessor.
Risk - and what really happens
Unexpected technical issue with an integration
Legacy ERP with no API documentation. An external system requires a format no one described. An integration planned for 2 weeks takes 8. The schedule slips. The client gets the explanation "it was not in scope" - and that is partly true and partly not.
How we handle this
Technical spike in discovery - for every risky integration
A non-standard integration? We deliver a proof-of-concept before signing the implementation contract. The estimate is then based on knowledge, not optimism. If something is impossible, it is better to know that before the contract.
Risk - and what really happens
Low adoption 6 months after go-live
System deployed. Sign-off signed. Vendor paid. Six months later: 40% of tickets still go by email "because it is faster". The board asks what they paid for. The IT manager has no answer. No one measured adoption, no one intervened.
How we handle this
Adoption as a hard KPI in the first 4 weeks
We measure the % of tickets inside the system vs. outside from day 1 after go-live. If adoption is below target we intervene concretely: micro-training, video materials, a conversation with team leaders. We do not wait for "it will sort itself out".
Risk - and what really happens
Production outage - and 45 minutes to figure out who calls whom
Critical incident, Friday evening. Everyone stares at each other. The playbook is "in the documentation" - no one knows where. Who has server access? What is the vendor's support number? 45 minutes on logistics before anyone starts fixing.
How we handle this
Incident playbook rehearsed before go-live - not written after
Before go-live: ready playbook + a rehearsal with your team. In hypercare: response to a critical incident within 2h during business hours. The first production outage cannot be the first lesson in response.
Risk - and what really happens
A vendor with a certificate, learning the product on your project
A vendor certificate confirms product knowledge - not project experience. The first real deployment in a complex environment is a few months of learning. The client pays for that education. Not with budget - with time and frustration.
How we handle this
Jakub: 4 years at MWT Solutions - the certified ManageEngine distributor
Implementation experience built in projects for large organizations from industrial, financial and public sectors - covered by NDA agreements. We do not publish names because of those agreements - we discuss them in person. We do not learn ManageEngine on your environment.
Structural safeguards
Why this project
will not fall apart.
Not because "we are good". Because we have specific mechanisms that catch problems before they become disasters. Each of these elements is a standard - not an optional add-on.
01
Weekly report - always, regardless of the situation
Every week, throughout the project: what was done, what is on the table, what decisions are needed on your side and whether the schedule holds. Good or bad news, the report arrives just as regularly. You do not learn about a problem from us on a call - you learn it from the report, in advance.
02
ADR - Architecture Decision Record, not slides
Every technical decision is justified in writing: why cloud and not on-prem, why this CMDB structure, why this integration in this way. If a year from now you ask "why does it work like that", you have the answer in writing. You are not looking for the person who remembers a conversation a year ago.
03
Change control - nothing "on the side"
Every scope change is a written impact estimate on time and budget within 48h. Minor changes (max 2h) are delivered without formalities. The rest: an annex. There is no "do it on the side" without consequences. The most common source of disputes after project closure is exactly the changes delivered without documentation.
04
Named accountability - not "our team"
On every project you have one point of contact on our side - a specific person, not "support". Jakub leads the technical implementation. Mateusz owns scope and communication with the board. When something needs a decision, you know exactly who to call.
05
Bad news, we come to you first
A delay, a discovered risk, a technical issue that changes scope - we inform you before you ask. We do not wait for the status call. We do not "quietly fix" anything that impacts schedule or budget. A project where the client is the last to learn about problems ends in dispute.
06
The project is yours - even if we do not finish it together
The ADR, configuration documentation, training recordings - all of this belongs to you from the moment of creation. If you end the project early or change partner, you have a complete set of documents. No vendor lock-in is not a slogan - it is a requirement we build into every project from day 1.
How we work
Principles that are not on paper.
Written scope before every engagement
We do not start any work without a written scope - whether it is a full project or a change request to an existing one. A verbal "do it on the side" does not exist in our project vocabulary.
Weekly reports - always, not only "when something happens"
Every week you get a short report: what is done, what is next, what needs your decision and whether the schedule holds. Good or bad news, the report comes just as regularly.
Bad news, we come to you first
A delay, a discovered risk, a technical issue - we inform you before you ask. We do not wait for the status call. We do not try to "quietly fix" anything that impacts schedule or budget.
The project is yours - even if we do not finish it
ADR, documentation, configuration - all of it belongs to you from the moment of creation. If the project ends early, you get the complete documentation. No lock-in on our methods or formats.
"No" is part of our service
If we think something is a bad idea, we say so. Before the implementation, not after. A certified partner that nods at everything is more expensive than one who occasionally stops and pushes back.
After go-live you are a client, not a closed project
We have clients who call us a year after go-live with a question. And we answer - not because of a contract, but because we know that this is the moment that either builds trust or destroys reputation.
Questions without a marketing filter
Frequently asked questions.
Honest answers.
A standard ManageEngine SDP implementation for 50-600 users: 8-10 weeks from kickoff. Multi-site implementations or full stack (SDP + OpManager + Endpoint Central): 12-16 weeks.
Before kickoff: discovery and contract signing typically take 1-2 weeks. We do not count client-side procurement decision time into the schedule - it is outside our control and can extend the project by weeks or months regardless of technical readiness.
Before kickoff: discovery and contract signing typically take 1-2 weeks. We do not count client-side procurement decision time into the schedule - it is outside our control and can extend the project by weeks or months regardless of technical readiness.
Discovery: Current-state report, problem map and project scope.
Architecture: Architecture Decision Record with diagram, rationale and licensing plan.
Implementation: Configured production environment + configuration documentation + weekly status reports.
UAT/Training: UAT protocol, training recordings, incident playbook (v1), go-live readiness checklist.
Go-live: Switchover protocol, first 48h report, active monitoring.
Hypercare: 4-week report, living documentation (final), operational runbook, maintenance plan.
Architecture: Architecture Decision Record with diagram, rationale and licensing plan.
Implementation: Configured production environment + configuration documentation + weekly status reports.
UAT/Training: UAT protocol, training recordings, incident playbook (v1), go-live readiness checklist.
Go-live: Switchover protocol, first 48h report, active monitoring.
Hypercare: 4-week report, living documentation (final), operational runbook, maintenance plan.
During hypercare (first 4 weeks): We are available like an internal team - hourly SLA during business hours (Mon-Fri, 8:00-17:00). For critical incidents outside business hours we follow an escalation path agreed individually in the contract. Every implementation ends with an incident playbook - a document describing what you do during common failures before you call us at all.
After hypercare: You can choose a maintenance contract (with SLA), prepaid support hour packages (no monthly commitment) or ad-hoc support. None of these models is required - it is your decision, without pressure.
After hypercare: You can choose a maintenance contract (with SLA), prepaid support hour packages (no monthly commitment) or ad-hoc support. None of these models is required - it is your decision, without pressure.
Minimum: 2-3h per week for the project sponsor (decisions, approvals) and 4-6h per week for the IT lead (configuration, tests). Discovery workshops: 1 day. Pre-go-live training: 4-8h for administrators, 2h for end users.
We do not require full availability - but a project without client-side decision availability takes longer. Every "waiting for an answer from the client for 3 weeks" extends the project. We inform you about this in advance.
We do not require full availability - but a project without client-side decision availability takes longer. Every "waiting for an answer from the client for 3 weeks" extends the project. We inform you about this in advance.
Scope changes are normal - we have a procedure for them. Every change is assessed for impact on time and budget, and the client gets a written estimate within 48h.
Minor configuration changes (up to 2h of work) are delivered within the project without formalities. Significant scope changes require an annex - we never deliver changes "on a handshake", because that is the most common source of disputes and misunderstandings after project closure.
Minor configuration changes (up to 2h of work) are delivered within the project without formalities. Significant scope changes require an annex - we never deliver changes "on a handshake", because that is the most common source of disputes and misunderstandings after project closure.
Yes - we deliver implementations fully remotely and it is our standard. The only stage where we prefer physical presence is discovery workshops (if the organization is complex) and optionally end-user training. Both also work well remotely - it is a matter of client preference.
On-premise implementations require VPN access to the client environment or a one-off trip to configure server hardware. This is always planned in advance and included in the schedule.
On-premise implementations require VPN access to the client environment or a one-off trip to configure server hardware. This is always planned in advance and included in the schedule.
You know what you want.
Or you do not yet - that is also OK.
A free consultation is not a sales call. It is 30 minutes where we tell you what your project would look like, what could go wrong and whether the budget you have is realistic for the scope you plan. No pressure. No pitch deck. If it does not make sense, we say so directly.
Three questions clients usually come with
Before deciding
"We have ManageEngine in mind, but we are not sure it is the right choice for us. Can you assess?" - Yes. That is a discovery session. It takes 1 day.
After a bad experience
"We had an implementation. It did not work. We want to try again, differently." - We have taken over several such projects. We know what to check.
Mid-project
"We are halfway through an implementation with another vendor and something is going wrong. Can you assess where?" - Yes. A mid-project audit is a separate service.
What you get on the consultation
Assessment of whether the scope fits your budget
Initial schedule (no commitment)
Identification of 2-3 main risks for your project
Answers to technical questions, no pitch deck
Written quote within 48h of the consultation.
Planning a specific project?
ManageEngine implementation - details
Products, 8-10 week schedule, outcome benchmarks and FAQ on costs and data migration.
Not ready for implementation yet?
IT analysis and advisory
Before you commit a budget to implementation - check whether the problem is well defined and whether the chosen system is right.
Free consultation, no commitment
Quote within 48h
Independent IT system selection
10 years of operational SLA experience
Transparent process from day 1
Project ownership yours from the start