Our own split of responsibilities is described on partnership and technologies.
Why groups look outside their own market
Three reasons, and only one of them is cost.
Rates. A Business Central consultant in London or Zurich is expensive, and for a subsidiary of twenty users the arithmetic of a domestic implementation often does not work at all. Central and Eastern European rates change that calculation without changing the platform.
Capacity. Established partners in Western markets have waiting lists. A project that could start in six weeks elsewhere starts in six months at home, and the subsidiary keeps running on whatever it runs on.
Local knowledge you cannot buy at home. This is the one that actually matters and gets discussed least. If the entity being migrated is in Ukraine, a partner who can read the existing 1C configuration and knows Ukrainian statutory accounting is not a cost saving — they are the only people who can do that part of the work at all.
What splits well and what does not
The failure mode in distributed projects is not distance. It is an unclear boundary between who owns what.
| Work | Splits well | Why |
|---|---|---|
| Local statutory layer | Yes, entirely local | Compliance is local by definition; nobody else can own it |
| Data migration from a local system | Yes, entirely local | Requires reading the source system and its language |
| Extensions and development | Yes, works well remotely | Specification in, tested code out; distance is irrelevant |
| Training the local team | Yes, must be local | Needs the local language and knowledge of local processes |
| Group chart of accounts and template | No, keep central | Group-wide decision requiring group context |
| Consolidation design | No, keep central | Depends on group reporting policy |
| Process redesign at group level | No, keep central | Needs authority nobody external has |
The pattern that works: the group keeps the template and the decisions, the local partner owns everything specific to the entity and its jurisdiction. The pattern that fails: both assume the other owns the statutory layer, and it is discovered in month four.
The question everyone asks and nobody writes down
If the partner is Ukrainian, there is a question in the room that rarely gets asked directly. It deserves a straight answer rather than a marketing one.
The IT sector has continued to operate throughout, and the practical arrangements are well established by now: distributed teams, cloud infrastructure outside the country, backup power and connectivity as standard, and staff spread across locations rather than concentrated in one office. Ukrainian IT firms have been delivering to Western clients continuously since 2022, and the sector's export figures reflect that.
What that means for you concretely: ask about continuity arrangements the same way you would ask any supplier — named backup people for each role, where the infrastructure sits, what happens if one location is unreachable. A serious partner has these answers ready and in writing. Treat vagueness as you would from any supplier, and specificity likewise.
The honest framing is that this is a supplier risk to be assessed with evidence, not a reason to dismiss and not a reason to hand-wave. Groups that have worked with Ukrainian teams generally report the continuity planning is more rigorous than what they get domestically, precisely because it has been tested.
Time zones, language and the practical mechanics
Time zones. Kyiv is UTC+2 or +3. That is one to two hours ahead of London, an hour ahead of most of continental Europe, and a working overlap of several hours with the US East Coast in the morning. For European groups it is effectively the same working day; for the US it means scheduling calls before lunch.
Language. English is standard in Ukrainian IT. What matters more is whether the same firm can also work in Ukrainian, because the local finance team will need training and documentation in their own language. A partner who can only do one of the two is a problem in either direction.
Contracting. Most established firms invoice through a European entity, which removes most of the friction around payments and VAT for EU and UK clients. Ask early; it changes your procurement path.
Meetings. A distributed project needs more structure than a local one: a fixed weekly call, written decisions after every meeting, and a single shared list of open questions. This is unglamorous and it is what actually determines whether the project runs smoothly.
What belongs in the contract
- The boundary. Which partner owns which layer, named explicitly. This single clause prevents the most expensive category of dispute.
- Localisation maintenance. Who updates it when tax law changes, how quickly, and whether it is billed separately.
- Code ownership. What transfers to you if the relationship ends, and in what form.
- Continuity. Named backups per role and where the infrastructure sits.
- Data handling. Where the environment is provisioned and who has access — usually an EU region, which answers most group IT policy questions at once.
- Support after go-live. Specifically weeks two and three, which is when the real issues surface.
When this is the wrong idea
- The work is genuinely group-wide. Redesigning processes across six countries needs authority and context that no external partner has.
- Your procurement cannot contract abroad. Some regulated groups genuinely cannot. Better to know at the start.
- Nobody on your side can own the relationship. Distributed projects need more client attention, not less. Without a named owner, distance amplifies every problem.
- You want one throat to choke. A legitimate preference. Two partners means two contracts and a boundary to manage, and if that is unacceptable, accept the higher cost of a single provider instead.
If the entity in question runs 1C, the specifics of that situation are covered in your Ukrainian subsidiary runs 1C, and the general selection criteria in how to choose an implementation partner.
Frequently asked questions
Is it realistic to work with a Ukrainian IT partner?
The sector has operated continuously and exports have been sustained throughout, with distributed teams, infrastructure outside the country and backup power as standard practice. Assess it as you would any supplier risk: ask for named backups per role, where infrastructure sits, and what happens if a location is unreachable. A serious partner has those answers in writing.
What should stay with our existing partner?
The group chart of accounts, consolidation design and any process redesign that spans entities. These need group authority and context. The local partner takes the statutory layer, migration from the local system, extensions and training.
How does the time zone work?
Kyiv is UTC+2 or +3 — one to two hours ahead of London and effectively the same working day for European groups. For US East Coast teams there is a solid morning overlap, which means scheduling recurring calls before lunch your time.
Can we contract with a European entity?
Most established Ukrainian firms invoice through an EU entity, which removes most procurement and VAT friction for EU and UK clients. Worth asking at the first conversation, because it determines your procurement route.
Who trains the local finance team?
The local partner, in the local language. This is not a place to economise: training delivered in English to a team that works in Ukrainian is the reliable way to end up with a system nobody uses and spreadsheets that reappear within a quarter.
Where will our data be hosted?
Business Central Online runs in Microsoft datacentres, and for European groups the environment is normally provisioned in an EU region. The partner has administrative access to the environment, not custody of the data, which is usually the answer group IT policy is looking for.