How to choose an IT systems integrator

A good integrator first establishes the business outcome, boundaries of responsibility, and data sources, and only then designs the connections. When selecting a provider, assess not only its knowledge of systems but also its approach to testing, documentation, maintenance, and knowledge transfer. The safer choice is a provider that takes responsibility for the entire flow between systems, not just its own part.

This guide will help you prepare comparable questions for providers, identify the right type of solution, and determine the next step before requesting a quote.

When do you need an integrator, and when is standard configuration enough?

Standard configuration is usually enough when the requirement fits within one system, the vendor has anticipated the scenario, and implementation does not change responsibility for the data. Examples include enabling a ready-made module, configuring an approval workflow, or using a connector maintained by the vendor. Testing and a business owner are still required, but the project does not involve designing an entire flow across several solutions.

An integrator is needed when a process runs through an ERP, document workflow system, CRM, data warehouse, BI platform, or custom application. The company must then establish which system is the source of each piece of information, when data moves forward, how errors are detected, and who is responsible for resolving them. Simply “connecting the APIs” does not answer these questions.

In practice, the dividing line is not between an off-the-shelf system and custom code. A sound provider first uses the standard features, then examines available interfaces and extensions, and writes code where the process or architecture requires it. This prevents the company from paying to recreate functions it already has or making a critical process dependent on unnecessary modifications.

Imagine an accounting specialist who receives an invoice, searches the ERP for the order, requests an expense description by email, and tracks approval in a spreadsheet. She spends time checking the status, while the company risks the document becoming stuck without an owner or moving forward without a complete decision. This is not merely a systems connection issue. The process, roles, permissions, deadlines, exceptions, and responsibility for data all need to be established.

When the bottleneck involves document workflows, approvals, permissions, deadlines, or shared rules for multiple companies, the first solution to examine is AMODIT and how it is implemented as part of process automation. The platform includes ready-made process mechanisms and AI functions: AMODIT Copilot, an AI agent, AskAI, and agentic rules. AI prepares a suggestion or working material, and the responsible person reviews the result and makes the decision. The integrator connects the process with the ERP and other systems and establishes a clear division of responsibility.

Do documents circulate among systems, companies, and approvers? Describe the current workflow and where cases most often become stuck. Discuss a document workflow in AMODIT →

Which integrator selection criteria matter most?

Price and timeline matter, but they say little without a comparable scope. Two proposals labeled “integration” can describe entirely different responsibilities: from a one-time file transfer to a monitored process with error handling, testing, and post-launch support. Assess seven areas before comparing quotes.

Does the provider understand the systems and their interfaces?

This is not simply about a list of technologies. The integrator should understand system version limitations, available APIs, file formats, message queues, authentication mechanisms, and interface licensing rules. It should also identify the system of record for each type of data and describe validation, retries, duplicates, and error messages.

Ask the provider to walk through one flow from beginning to end. If the explanation stops at “the systems will be connected,” there is not enough information to assess the risk.

Who is responsible for the whole flow and the boundaries between systems?

Most disputes arise not within a single system, but at the boundaries between systems. The ERP sent a document, the process platform did not accept it, and the report shows an outdated status. Each provider can then claim that its own part works correctly.

A good delivery model names one owner for diagnosing the entire flow. The contract and architecture should specify who monitors the integration, who analyzes an incident, how providers work together, and where the provider’s responsibility ends.

How does the provider approach security and compliance?

Security should be addressed before the architecture is selected, not just before launch. Review the rules for environment access, secret storage, activity logging, data minimization, retention, backups, and removal of permissions after the work ends. Ask how the solution will meet the requirements of IT, security, purchasing, the Data Protection Officer, and compliance teams in your organization.

An integrator does not replace a lawyer or Data Protection Officer. It should, however, translate approved requirements into architecture, configuration, documentation, and maintenance.

What is the delivery and testing approach?

The provider should present project stages, deliverables, and acceptance criteria. Integration testing must cover not only successful flows but also failure scenarios: no response from a system, incomplete data, a duplicate, a changed format, a retry, and recovery after an interruption.

Ask about test environments, integration and acceptance testing, the involvement of business users, and the rollback plan. A good demonstration shows error handling, not just the ideal scenario.

What documentation and knowledge will the company receive?

Documentation should describe the post-implementation state, not only the assumptions made before the project. At minimum, it should include a flow diagram, data mappings, interfaces and dependencies, environment configuration, deployment procedure, monitoring, incident handling, and a recovery procedure.

Establish who updates the documentation and how the client’s team takes over the knowledge. A handover workshop, operating instructions, and repository access reduce dependence on a single person on either side.

What support and SLA model applies after launch?

A warranty covers the correction of defects under its terms. An SLA organizes ongoing service: ticket categories, support hours, response and resolution times, contact channels, priorities, and the scope of enhancements. These are two different mechanisms.

Before signing the contract, establish who monitors the integration, how an incident is reported, and what happens outside business hours. A critical process should not depend on the ad hoc availability of the solution’s original developer.

How should you verify a provider’s references?

Look for similarity in complexity, not just the same industry. A project connecting several systems, multiple roles, and critical data can be a better reference point than a simple implementation in an identical sector. Ask for a description of the challenge, scope of responsibility, acceptance method, and maintenance model.

An anonymous case study is also valuable if it clearly shows the starting point, work completed, and outcome for the organization. A list of logos alone does not explain what the provider actually delivered.

Which risks most often surface after the contract is signed?

Point-to-point integrations without documentation. Each new connection is built separately, uses different error-handling rules, and no one sees the complete dependency map. A change to one system stops several processes.
Dependence on one person. Only the original developer knows the configuration, exceptions, and deployment procedure. That person’s vacation or departure turns a simple change into an investigation from the beginning.
No responsibility for system boundaries. Each provider confirms that its application works, but no one leads the diagnosis of the complete flow.
Acceptance based only on the successful scenario. The integration passes the demonstration, but no one knows how it will handle a duplicate, an unavailable system, or incorrect data.
Maintenance agreed after launch. The company learns only during the first outage who receives the ticket, has access to the environment, and understands the solution.

Turn these risks into proposal and acceptance requirements. This lets you compare concrete approaches to reducing operational dependencies rather than sales presentations.

What questions should you ask an integrator before making a choice?

Use this list during a meeting, request for proposal, or contract scope review:

Which system will be the source of each critical piece of information?
Which interfaces are available, and what version, license, or performance limits apply?
Who is responsible for the complete flow when an error occurs between systems?
How does the integration detect errors, duplicates, and missing data, and how does it retry operations?
Which environments, access rights, and data will the provider need?
Which tests are included in the proposal, who prepares them, and who approves the result?
What are the launch, rollback, and disaster recovery procedures?
Which documentation, code, configuration, and knowledge will the company receive?
Who updates the documentation after subsequent changes?
What warranty, post-implementation support, and SLA model are available?
What happens to data, accounts, and access rights after the engagement ends?
Which project best demonstrates a similar level of complexity and responsibility?

Ask for the answers to be included in the proposal or a contract appendix. Agreements recorded only in a presentation or meeting notes are difficult to enforce later.

What does a well-run integration project look like?

A good project does not start with coding. It begins with a shared view of the process, data, and responsibilities, and each subsequent stage produces verifiable deliverables:

Objective and scope. The business owner describes the challenge, the intended way of working, and the critical processes.
Inventory. The team lists the systems, versions, interfaces, data owners, dependencies, and security constraints.
Solution design. The team defines the flows, mappings, error rules, permissions, monitoring, and division of responsibility.
Phased delivery. The most important flow works earlier, so the assumptions can be tested before the entire solution is expanded.
Testing. The technical team and business users test successful scenarios, exceptions, failures, and recovery.
Launch and handover. The company receives documentation of the post-implementation state, operating instructions, and the knowledge required for support.
Maintenance and development. Monitoring, ticket handling, SLAs, and the rules for future changes are agreed before production launch.

At every stage, it should be clear what is ready, who verifies it, and which risks remain open. This matters more than the name of the methodology in the proposal.

What distinguishes the Astrafox approach?

This section describes our approach, separating neutral selection criteria from information about the provider. One team is responsible for the process, systems, and data, so responsibility for solution boundaries is not passed among independent providers without an owner for the whole flow.

We first check whether the requirement fits within the standard capabilities of the solution already in use. If it concerns processes, documents, approvals, and accountability, we start with AMODIT. When invoices need to connect to KSeF (Poland’s National e-Invoicing System) and any ERP or accounting system, we use our own KSeF Connector. KSeF Connector handles the technical exchange of invoices, while AMODIT manages their coding, approval, and subsequent workflow—each solution is responsible for a different part of the process.

When the problem involves fragmented sources and manual data preparation, DataFlow organizes flows from ERPs, CRMs, databases, APIs, and files for reporting. When content-intensive work is the bottleneck, see our other products: the AI Agent for RFQ Responses, AI Agent for Sales Proposals, and AI Agent for Contract Review. They most often operate within a process on the AMODIT platform, but we also integrate them directly with company systems.

When ready-made components do not cover the process, we build custom software and integrations around the existing environment. Only then do we determine which functions should remain in systems supplied by other vendors. If the company uses Comarch ERP XL or Optima and the issue lies within the ERP itself, we work as a Comarch Authorized Integrator and partner since 2003. The answer is therefore not always a new application: sometimes configuration is enough, while other situations require a controlled process, a data layer, or code connecting systems.

Our scope covers analysis, design, delivery, testing, launch, and ongoing support. At the outset, we also establish who is responsible for each system and what the client’s team will receive after implementation.

What do companies most often ask when choosing an integrator?

Does an integrator need in-depth knowledge of every system we use?

It does not need in-depth knowledge of every system. It must, however, be able to use the interfaces provided by the company that supplies or supports that system: APIs, web services, imports and exports, and documentation. Check whether the integrator understands the key systems or has a proven way to work with their providers. The most important question is who designs and manages the complete flow, understands the available interfaces, and takes responsibility for diagnosing issues at solution boundaries.

Is a fixed price or time-and-materials model better?

The model should reflect the maturity of the scope. A fixed price requires clearly defined assumptions, inputs, and acceptance criteria. When the solution cannot be estimated reliably before analysis, it is safer to commission a separate discovery stage and price the implementation afterward.

Can a new integrator take over existing connections?

Yes, but the transition should begin with an audit of the architecture, code, configuration, access rights, documentation, monitoring, and open incidents. Only after this diagnosis can the parties define the scope of responsibility, close the gaps, and plan further development.

What should we prepare before the first meeting with a provider?

A description of the challenge, a list of systems involved in the process, an example information flow, and the people responsible on the business and IT sides are enough. You do not need to share confidential data or a complete technical specification at the outset.

What are you looking for?

How to choose an IT systems integrator: a guide for companies