Hand over the part of the work that never finishes.
Bring us the toolchain and the open source estate beneath it, and we will tell you what we would take on first and what we would leave alone. That second half is the useful part of the answer.
Delivered as a single-tenant dedicated instance, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today. Air-gapped and sovereign are in development.
The estate you already run, and what keeps slipping.
Four shapes this conversation usually takes. Three of them are a situation; the fourth is a date.
This is the ordinary case and it is what the motion exists for. Version currency becomes our work rather than a ticket waiting for a quiet week.
AskWhat is the oldest version you are still running in production?
The pager goes to us instead, to a named engineer with a current runbook.
AskWho would get their evenings back?
Scanners report findings with context into the work; they do not block, and you decide the order.
AskWhich finding has been open longest, and why?
This is the sharpest version of the conversation because the scope is set by somebody else and the deadline is real. Bring the date and the platform. What happens on the day if nothing moves? The Atlassian Data Center path →
What we would want to know on the first call.
Less a checklist than the four things that make a scoping conversation useful rather than exploratory. None of them needs preparing in advance; if you know two of the four, write anyway.
Which platforms, and which versions
The tools your engineers use every day and roughly where each one sits. Approximate is fine. Nobody has this exactly right and pretending otherwise wastes the call.
Who holds the pager today
Whether that is a named team, one person, or nobody in particular. The answer changes what we would take on first.
How change gets approved
We run to your change control, so the shape of it is the shape of the service. An upgrade is scheduled through your process, at a time you agree.
What is actually forcing the question
A deadline, a departure, an audit finding, or simply that it has been deferred twice. This is the one that decides whether now is the right time.
What we would take on, and what we would leave.
A scoped answer rather than a proposal that assumes the answer is everything.
What you would have
A scope with a boundary on it. What we would operate, what stays with your team, and the order we would do it in.
The service levels and the change path. Held to your change control, with named engineers rather than a rota and an address.
An honest view of what we would not touch. Some of an estate is better left where it is, and saying which part is most of the value of the first conversation.
What we will not give you
A published operating metric. There is no uptime figure, no service-level number and no operating metric published anywhere on this site. Twenty-one years of doing the work is the evidence, and we would rather say that than print a number nobody signed off.
A shared or multi-tenant option. A single-tenant dedicated instance is the only deployment model on offer, and there is no SaaS tier behind it.
A date for what is in development. Air-gapped and sovereign are in development.
Two engagements are written up and cleared for use by the customer, anonymised. Read them →
Tell us what you run.
The platforms, roughly which versions, and what is forcing the question. We will come back with what we would take on first and what we would leave alone.