IT project delivery · Győr
How we scope, deliver, and support IT projects
Most IT projects fail in the planning, not the technology. This is what an engagement with ALPHATECH looks like from the first conversation to steady state — assessment, migration, service desk, and observability, written down and agreed.
Inventory first. Servers, endpoints, cloud tenants, line-of-business apps — and the people who use them.
A written proposal: what is included, what is excluded, what it costs, how long it takes, response times.
Staged cutover, tested in batches, scheduled around your business calendar — with a rollback path.
Assessment comes first
Before we propose anything, we look at what you run. That means inventorying servers, endpoints, cloud tenants, and line-of-business applications, and talking to the people who use them. We ask what breaks, what is slow, and what keeps you up at night.
The output is a written summary of your current state and the risks we see — a plain document, not a slide deck. You keep it whether or not you engage us further. It is yours to share with your board, your accountant, or another supplier if you want a second opinion.
Skipping this step is how projects end up solving the wrong problem. We would rather spend a week finding out that the real bottleneck is your file server than spend three months migrating something that was never the issue.
Scoping and the written proposal
The proposal states what is included, what is excluded, what it costs, and how long it takes. Response times for support work are specified, not implied. Change requests have a defined process. If something is uncertain, we say so rather than burying it in an appendix.
Work staged in batches, tested before each move
Clients tell us this is unusual in the Hungarian market, where verbal agreements and vague scopes are common. It is also the single biggest reason our projects finish close to schedule.
Every proposal states
Migration and deployment
When a project involves moving workloads, we plan the cutover in stages and test each one. Users get instructions before changes land, not after.
Most clients cannot flip everything at once, and pretending otherwise creates the outage. We keep on-premise and cloud systems working together during the transition, then retire the old pieces once the new ones have run cleanly.
Staged cutovers, tested in batches, and a rollback path for every move.
Ongoing service desk
Once systems are live, support takes over. Tickets come in, get triaged, and get resolved or escalated. We track what was reported and how it was handled, so patterns become visible instead of staying anecdotal.
If the same issue appears five times in a month, that is a signal to fix the underlying cause rather than close the sixth ticket and move on. Clients on managed services agreements get a regular summary of activity, which makes renewals a factual conversation instead of a negotiation.
Observability and monitoring
We monitor what matters to your operations: server health, backup completion, disk space, network availability, and the endpoints that production depends on. Alerts go to us first, so most problems are handled before users notice.
Where a client has specific systems worth watching, we add them to the monitoring scope. This is not surveillance of employees; it is operational visibility, and we are explicit about the distinction when we set it up — which systems, which metrics, who can see the reports.
Project delivery for custom software
Custom development runs on shorter cycles with visible progress. We agree on what the first version needs to do, build it, and put it in front of the people who will use it. Feedback goes into the next iteration.
Documentation is written as we go, not reconstructed at the end. When the project finishes, you have working software, source code, and instructions for whoever maintains it next — in-house or otherwise.
A short written scope of what version one must do — and what it deliberately will not do yet.
Working software in front of the people who will use it, early enough to change course.
Notes written alongside the work, not at the end.
Handover and documentation
Every engagement ends with documentation, whether it ends because the project is done or because you decide to take IT in-house. Network diagrams, credentials, configuration records, and support procedures are handed over in a usable form.
We do not hold clients hostage with undocumented systems. It is better for everyone if leaving is easy and staying is a choice.
Support boundaries and escalation
Standard support covers agreed hours and agreed systems. Outside that scope, we quote before we work — no surprise invoice after the fact.
Emergencies happen, and when they do we respond. We do distinguish between an emergency and an out-of-hours request with a clear price attached, because conflating the two is how support relationships sour.
Reviewing the arrangement
Once a year, at minimum, we sit down and look at what changed. Staff counts shift, systems get replaced, and priorities move. An agreement that fit two years ago may not fit now.
We adjust scope, price, and priorities accordingly. Clients who stay with us for years do so because the arrangement keeps matching their actual situation, not because they are locked in by a contract that nobody wants to reopen.
Questions before you engage us
Short answers to the things clients ask in the first conversation.
Do we have to commit to a managed services agreement after the assessment?
No. The assessment output is a written summary of your current state and the risks we see, and you keep it whether or not you engage us further. Some clients take it, fix the easy items themselves, and come back a year later when something bigger comes up.
Can you migrate us to the cloud without taking everything offline?
Yes, in most cases. Mailbox migrations run in batches, file shares move with a rollback path, and hybrid environments keep on-premise and cloud systems working together during the transition. Server replacements are scheduled around your business calendar rather than ours, so the cutover lands in a quiet week if that is what you need.
What happens if we decide to bring IT back in-house?
You get documentation: network diagrams, credentials, configuration records, and support procedures, handed over in a usable form. We do not hold clients hostage with undocumented systems. Leaving should be easy, and staying should be a choice you keep making.
Does monitoring mean watching our staff?
No. We watch systems, not people: server health, backup completion, disk space, network availability, and the endpoints production depends on. The scope is agreed with you in writing and we say plainly which systems and metrics are covered, and who sees the reports.
Start with the assessment
If you want to judge whether this method fits your team, the assessment is the honest place to begin. Tell us what you run and what keeps breaking, and we will tell you what we see — including the parts you may not want to hear.