Frequently Asked Questions

We work with organisations that need business and technology change to operate as one programme—particularly where processes, applications, data, cloud services and multiple stakeholders must connect. The starting point may be a defined implementation, an underperforming operation, a legacy constraint or a decision that still needs shaping.

No. A clear business priority or operating problem is enough to begin. We can help turn that context into outcomes, boundaries, dependencies and decision criteria before detailed requirements or platform commitments are made.

Yes. We can review the current operating model, architecture, delivery position, risks and evidence, then identify what should be retained, corrected, connected, extended or reconsidered. The review scope is agreed so it produces decisions rather than another broad document.

Yes. A focused workshop or discovery engagement can be useful when the priority is understood but the right response, scope or sequence is not yet clear. We define the questions to resolve, the people who need to contribute and the decisions or artefacts expected at the end.

Yes. The scale of governance and delivery should match the organisation and the consequence of the change. Mid-market engagements often benefit from a pragmatic combination of established platforms, targeted integration and tailored capabilities without unnecessary enterprise complexity.

We consider the business outcome, operating context, required capabilities, delivery constraints and where accountable ownership is needed. If the requirement is outside our strengths or another route would serve you better, we aim to make that clear early.

No. We use the most appropriate mix of existing platforms, configuration, integration, extensions and tailored engineering. The objective is not to maximise custom code; it is to create a coherent capability that fits the business and can be operated responsibly.

Yes. We define responsibilities, decision rights, interfaces and evidence so client teams, incumbent suppliers and specialist partners can contribute without blurred ownership. The collaboration model is shaped around the programme rather than imposed as a fixed structure.

We make assumptions and dependencies visible, establish governance early, prove consequential elements before scaling, and connect technical acceptance with business readiness. Delivery is staged around usable evidence, not activity alone.

It depends on the starting point, scope, dependencies and level of organisational change involved. A focused assessment or proof may take weeks, while a multi-system transformation may run in controlled phases over several months. We establish a realistic sequence after understanding the work rather than offering a standard duration.

Yes, where a responsible transition is possible. We first establish the actual delivery state, architecture, code and documentation quality, contractual boundaries, unresolved risks and stakeholder expectations. The recovery plan then separates urgent stabilisation from longer-term correction and improvement.

Relevant users contribute to process understanding, priorities, prototypes, acceptance and readiness. We use their operational knowledge without transferring delivery accountability to them, and we plan participation so feedback arrives when it can still influence the outcome.

Microsoft Azure, Microsoft 365, Power Platform, Dynamics 365 and Business Central are important parts of our capability, but our work is not limited to a single vendor. We integrate specialised, legacy and third-party platforms where they remain the right part of the operating landscape.

Usually, yes—subject to the system's supported interfaces, data quality, security constraints and operational ownership. Where direct integration is unsafe or impractical, we make the limitation explicit and evaluate controlled alternatives.

We begin with the decision, action or service outcome that should improve. Trusted inputs, ownership, permissible use, controls, human oversight and feedback are designed before a model or tool is treated as the solution.

Yes. Data migration is treated as a controlled business transition rather than a simple technical transfer. We agree ownership, mapping, cleansing, reconciliation, cutover, retention and validation so the receiving system begins with data that is usable and accountable.

Yes. We assess whether existing applications and platforms can be retained, simplified, connected or extended before recommending replacement. A new system is justified only when the current estate cannot responsibly support the required outcome or direction.

Not every dependency can or should be eliminated, but it should be understood. We make platform-specific choices explicit, favour supported interfaces and portable data where practical, and consider exit, interoperability and operational ownership when those factors matter to the decision.

They are treated as design and operating requirements, not final-stage checks. Applicable obligations, identity, access, data handling, logging, resilience and assurance are established according to the solution, region and client environment. Formal commitments are recorded in the engagement documentation.

Ownership and licensing are agreed transparently before delivery. Client-specific deliverables, pre-existing materials, third-party components and reusable accelerators are distinguished in the contract so there is no ambiguity later.

Yes. Support may include service transition, monitoring, incident response, maintenance, release management and planned improvement. The service model, coverage, response expectations and responsibilities are matched to operational criticality.

Yes. The required documentation is agreed according to the solution and operating model and may include architecture, configuration, interfaces, deployment, support procedures and user guidance. Knowledge transfer is planned throughout delivery and transition rather than left to the final day.

Hosting follows the selected architecture, client policy, regulatory obligations and regional requirements. Solutions may operate in a client-controlled cloud tenant, an agreed hosted environment, on-premises infrastructure or a hybrid model. The responsibilities and access boundaries are documented before implementation.

Access is limited according to role, purpose and the client’s approved controls. Identity, privileged access, development and production separation, information sharing, logging and offboarding requirements are agreed for the engagement and reviewed as responsibilities change.

Yes. ToqXcel is designed for coordinated international engagement with local business context and distributed delivery capability. The working rhythm, decision availability, language, regulatory considerations and on-site needs are agreed for each engagement.

The commercial model follows the certainty of the work. A defined deliverable may suit a fixed scope, while discovery, evolving products or managed capacity may require staged, time-based or outcome-linked arrangements. Assumptions, exclusions and change controls are made visible in every case.

We confirm our understanding, identify what remains unknown and recommend a proportionate next step. That may be no further action, a focused workshop, an assessment, a proof, or a scoped delivery proposal—depending on what the decision genuinely requires.

Yes. The model depends on the work, location, stakeholder needs, security constraints and value of physical presence at key stages. Many engagements combine remote delivery with purposeful on-site discovery, workshops, transition or governance activity.

Start timing depends on the required skills, scope clarity, onboarding, access and existing commitments. After the initial discussion, we can confirm availability and identify any discovery, commercial or environment preparation needed before productive work begins.

We establish the agreed baseline, assumptions, exclusions and approval route at the outset. Proposed changes are assessed for value and their effect on cost, time, risk and dependencies before they are accepted, deferred or exchanged for other scope.