Engineers in your team for the duration of a project, or taking over system maintenance, ending with knowledge transfer to your people.
See the serviceKnowledge transfer
The system, its access and the knowledge of it in your people's hands, tested so that your team releases a new version and fixes a failure on its own, without calling the contractor.
Scope
What clients come to us with
The board does not want to depend on one contractor
The company orders a system and assumes from the outset that after acceptance it will be run by its own IT department or by another supplier. The security policy or the purchasing rules require it. The condition is stated in the request for proposal: knowledge of the system has to stay in the company.
The project is ending and has to be handed to someone
A system built by an external team has passed acceptance. The board wants to sign the final acceptance record knowing that the IT department knows where the servers are, who has the passwords and what to do when the system stops. The code and documentation exist, but no one on the company's side has released a single version on their own.
Maintenance is to come back in-house
For a while the system was run by a contractor. The company has hired its own engineers or is changing supplier, and wants the transition to happen without interrupting the system. It needs a plan: who takes over what, in what order, and how to tell that the new team is coping.
Scope
What we do
Knowledge transfer is planned work in which the system, its access and the way it is run pass from us to your people, with the scope, deadline and final test set out in the contract.
We write the documentation for the person who will come after us and will never meet us: where the system gets its data, where it runs, how to start it from scratch, which settings can be changed. We test it simply: a person from your team carries out a described step using only the text, and we correct every place where they had to ask.
Working in pairs means that for an agreed period every task on the system is carried out by a person from your team together with one of ours: first they watch, then they do it under supervision, and finally on their own. This covers requests, fixes and releases, meaning moving changes from the code into the running system.
We hand over access and keys: administrator accounts for servers and the cloud, the domains under which the system is available, the keys that encrypt connections, database passwords and accounts with suppliers. All access is moved to your company's accounts, and we close our accounts in your presence. The result is a register: what, where, who has access and when it expires.
Operating instructions are short procedures for typical situations: the system is not responding, a new version has to be released or rolled back, a user has to be added, data has to be restored from a backup. A person from your team has carried out each one using the text.
At the end comes the test: your team releases a new version and fixes a failure on its own, while we watch and note where the instructions fell short. The transfer ends when the test passes without our help.
If we are building the system for you, the transfer starts on day one: your person is on the project from the beginning, the documentation is written together with the code, and access sits on the company's accounts. If we run your system under a maintenance contract, the transfer is the last stage of the contract, for an agreed period before it ends. Taking over a system built by someone else is a separate scope.
After we leave, you keep: the code in your repository, the store of code with a record of every change, the documentation, the instructions, the access register and a team that has passed the test. If a problem comes up that the instructions do not cover, you can call us back. The call-out rules, response time and billing method are set out in the contract, so that they do not have to be agreed on the day of a failure.
Scope
What you get
- Documentation for the successor: how the system is built, starting it from scratch, settings, tested by a person from your team.
- A register of access and keys moved to the company's accounts, with expiry dates and written confirmation that our accounts are closed.
- Operating instructions: failures, releasing and rolling back a version, users and permissions, backups.
- A test record: your team released a version and fixed a failure on its own, and gaps in the instructions were filled.
- Call-out rules set out in the contract.
Scope
How the work runs
- We agree who takes over the system and what they need to be able to do. We list the tasks we currently carry out on the system and assign each to a person from your team. Result: a transfer plan with tasks, the people on your side and the date of the test.
- We work in pairs and write for the successor. Your people handle requests, fixes and releases with us, and every question they ask goes into the documentation. Result: documentation and instructions tested in real work.
- We hand over access. We move accounts, keys and supplier contracts to the company, close our access and draw up the register. Result: an access register confirmed by both sides.
- We run the test and leave. Your team releases a version and fixes a failure on its own; we note the gaps and fill them. Result: a signed transfer record and the system run by your team.
Scope
Questions the board should ask the contractor before the contract ends
- Is knowledge transfer written into the contract as a deliverable with a deadline and acceptance criteria?
- In whose name are the servers, domains and cloud accounts registered, and what will happen to them on the day the contract ends?
- Has anyone from our company released at least one version of the system on their own, without the contractor?
- Who updates the documentation with every change, and who has checked that the system can be started from scratch using it?
- If a problem the instructions do not cover comes up after the contractor leaves, on what terms do they come back and how quickly do they respond?
- Which parts of the system run under the contractor's licence or account, and what will happen to them after the contractor leaves?
The scope of the transfer depends on who is to run the system and what they know about it today, so the first step is an analysis: a review of the system, access and documentation, ending with a transfer plan.
Parent service
Team and maintenance
Book a meeting
Book a conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Phone: +48 455 406 404
Dedicated teams
A whole team with a lead that works only on your project, reports to the board on a fixed schedule and leaves with you everything needed to run the system.
See the scope
Skills augmentation
One missing role in your project filled by a person from our team, chosen in conversation with your people, working under your manager, with a replacement when needed.
See the scope
Taking over maintenance
A system built by someone else under ongoing care: reviewed before takeover, with a list of gaps, a plan for the first clean-up and a single queue for requests.
See the scopeHow we start
A conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Analysis under an NDA
We examine the process and the systems and hand over a recommendation with a scope of work. You know the scope, deadline and price of the analysis before it starts.
Offer
You receive the scope, team, schedule and price of the implementation. You decide whether we go ahead.
The cost of the analysis is credited towards the implementation if you order it.
Phone: +48 455 406 404 E-mail: contact@aliaxit.com