An accountant launches Optima in the morning and instead of the login screen sees the message "Failed to retrieve information about available modules. The program is running in STARTUP VERSION". After five minutes it turns out that the Key Manager on the server lost connection to Comarch's servers eight hours earlier - someone changed the firewall rule in the meantime "to make it safer". Until then, the modules were being served from cache, so no one noticed the problem. Five workstations are down, KSeF is waiting, and no one in the company knows where to start.
This is not a made-up scenario, but a typical example of why IT support for a company using Comarch ERP Optima requires a different mindset than supporting a standard SQL application. Optima is not one program, but an ecosystem: the SQL engine, client application, Key Manager, web modules (Comarch HRM, DMS, BI Point), synchronization with Comarch Mobile, integration with KSeF and increasingly - from 1 February 2026 - communication with Comarch servers enforced by the subscription model.
In IT support for companies using Optima, we keep running into the same few things that surprise people: that the license is a network service, that every module adds a separate piece of infrastructure, that Optima quarterly updates are one-way, and that from 2026 losing warranty continuity is not only a financial issue but an operational one.
Comarch ERP Optima is an ecosystem, not a single application
Optima in a classic installation is a 32-bit Windows application connecting to Microsoft SQL Server (supported versions 2016-2022, both Express and Standard or Enterprise; in new deployments we nevertheless recommend 2019 or later, because extended support for SQL Server 2016 ends on 14 July 2026). This is the description that appears in the documentation and that many administrators treat as the whole picture. In practice, correct operation of Optima requires at least four things at the same time:
a SQL server with the company database and configuration database (CDN_KNF_Konfiguracja),
an installed Key Manager as a Windows service,
network access to Comarch's servers (ml.comarch.pl and erp.comarch.pl over TCP 80 and 443) for virtual keys,
correct SQL Server configuration with the Polish_CI_AS collation and mixed authentication mode enabled.
Supporting modules include Comarch HRM on IIS for HR staff working through a browser, Comarch DMS with a separate database for document workflow, synchronization server for Comarch Mobile, Comarch BI Point for reports. Each has its own hardware requirements and its own update path.
In a company employing 25 people, where eight work in Optima, three through Comarch HRM, and one through Comarch Mobile in the field, the infrastructure is no longer just one SQL server, but several components that must be maintained consistently. That is why IT support for companies using Optima is, in practice, about making sure those components do not drift apart in versioning and that none of them is left unmonitored.
Key Manager - a single point that can stop an entire company
Key Manager is a separate Comarch application installed as the Windows service "Comarch ERP product key management", which intermediates between the client application and the license. Without it, Optima starts in DEMO mode, which is not suitable for real work.
Today, keys come in two variants: a physical HASP USB key or a virtual key activated by contacting Comarch's servers. The third variant - SoftHASP files (Softhasp.sig, Softhasp.dat on disk) - was supported until March 2021 and now appears only in very old, unupdated installations. In companies we take over with IT outsourcing, we most often see virtual keys because they eliminate the problem of a physical token. They do, however, have one limitation that must be known when designing the infrastructure: the virtual key requires contact with Comarch's servers at least once every 24 hours. If Key Manager loses connection for longer, modules stop being fetched and workstations cannot log in. In practice, lack of connectivity may be masked by the cache of downloaded modules - the system can appear to work normally for some time - but this does not remove the requirement for periodic communication. Sooner or later, a lockout occurs.
The practical consequences are threefold. First, Key Manager is usually installed on the same server as SQL - which looks sensible until you realize that when the server is restarted, both the database and the license are blocked at the same time. Second, the firewall in front of the server must have a permanent outbound rule for Comarch addresses - a one-time change to a "block outbound by default" policy can stop a company the next day. Third, Key Manager has a tab "Notify when the key loses contact with Comarch servers" - enabling it takes a minute and saves you from the situation described in the introduction.
In the companies where we provide IT support for Optima, we monitor Key Manager systemically. Our monitoring system standardly checks the status of the Windows service "Comarch ERP product key management" (technical name: ComarchML), the time since the last communication of the virtual key with Comarch's servers, and receives e-mail notifications configured in Key Manager itself. This is one of the things included in the fixed subscription - we call it "batteries included", because it is operational routine, not a separate project.
Comarch modules and their own infrastructure requirements
Comarch HRM is, for many companies, the second most important element of the ecosystem after Optima itself. It runs as a web application on IIS, uses a separate database (or separate schema), and requires a separate license in Key Manager. On the infrastructure side, this means: a server with IIS, an SSL certificate for the internal domain (if HRM is to be available to employees outside the office), reverse proxy if security requirements call for it, backup of the HRM database and the main database as a pair (drift between them can produce false HR data).
Comarch DMS adds yet another database and another application server - this time for document flow, purchase invoices and OCR. In the installations we maintain, DMS most often runs on a separate machine, because it generates a different load profile than accounting work in Optima - image processing and OCR burden the CPU and memory in a way that the SQL database on the same server will not "forgive".
Comarch Mobile, in turn, is the synchronization server between the mobile application used by sales representatives and the Optima database. Synchronization consumes a license in Key Manager based on the device identifier, and every phone change for a salesperson requires contact with Comarch support to release the mobile license. For the IT team, it is routine, as long as someone keeps track of it.
Comarch BI Point is reporting - simpler from an infrastructure standpoint, but with its own entry threshold: subscriptions for report users, limits on email recipients and a separate access module.
Each of these components means an additional database, an additional service and an additional set of firewall rules. That is why every Optima-HRM-DMS infrastructure audit starts with an inventory: what is installed, in which versions, with what backup system and who knows about it. In three out of four cases it turns out that the company has a Comarch module that IT had no idea about - because it was implemented by the accounting partner five years ago.
Quarterly versions and database conversions - where things can break
Comarch releases new versions of Optima on a quarterly cycle: 2026.0, 2026.1, 2026.2, 2026.3, plus hotfixes such as 2026.1.1. In 2026 the pace is even faster, because KSeF development forces further iterations. For the IT department this means an average of four full environment upgrades per year, each involving a database conversion.
Database conversion in Optima is one-way. After starting the update and converting the database from version 2025.2 to 2026.0, you cannot go back without restoring from backup. Failed conversions do happen - not as the norm, but as a real risk, especially with larger version jumps or databases with custom add-ons and modifications. One failed update can take a company offline for half a day if there is no current backup from before the attempt.
That is why, in the installations we maintain on the infrastructure side, we have a standing cooperation protocol with the client's implementation specialist around Optima updates: before each update we make a full database backup, provide a test machine with a copy of the production database to verify the conversion, and the production update itself takes place in a service window that we agree together with the Comarch partner responsible for the application. For companies with several databases (e.g. an accounting office serving 40 clients), converting all databases is a separate project in the calendar, not a one-click operation.
It is worth clearly separating the scope of roles here. Optima implementation, module configuration, accounting parameters and the database conversion itself are the domain of the Comarch partner or implementation specialist - and that is good, because it is their specialty. On the IT infrastructure side, we are responsible for the layer below: the server, SQL, network, Key Manager, backups, monitoring and security. In practice, it is cooperation - the Comarch partner handles the application, we ensure that the infrastructure beneath it is stable, secured and up to date. In many problems that at first glance look like an "Optima error", the solution lies on one side or the other, or on both - hence the importance of the communication channel between the implementation specialist and the client's IT department.
Added to this is the requirement for an active Comarch warranty (support). Version 2026 requires a warranty valid on 3 November 2025, and according to the manufacturer's announcements the open upgrade model is to be withdrawn from sale in May 2026. In practice, this would mean that a company that loses warranty continuity in the middle of 2026 will not be able to renew it in the old model after May - the only path to the current version with KSeF support will be to move to a subscription. Keeping track of warranty dates and negotiating terms is the responsibility of the Comarch partner, not infrastructure IT - however, it is useful for the technical team to know which model the client operates in, because it determines the response method when access is lost.
Subscription model from 2026 - license as part of infrastructure
From 1 February 2026, Comarch introduced a full subscription model for the desktop version of Optima. It replaced the previous perpetual license: instead of a one-time purchase and an annual warranty fee, the user pays a monthly fee for access to the system. Once the subscription expires, logging in to Optima is impossible.
From the IT department's perspective, this is a qualitative change. A license that until now was a capital purchase and a document in a drawer has become an ongoing service with its own interruption risk. According to the official subscription terms, payment delays exceeding 30 days entitle Comarch to block access to the software, and longer arrears may result in termination of the agreement. For a company in the middle of the accounting season - for example in April, before the annual filing deadline - this is a scenario no one wants to test.
Comarch offers three licensing variants, each with different implications for IT infrastructure:
Subscription on your own server - Optima runs at the client's site, monthly fee for modules, infrastructure maintained by the company or IT partner. This is analogous to the old on-premises model, the only difference is the payment model.
Standard Cloud - Optima runs in Comarch's Data Center, the client connects through remote desktop. Backup, SQL server and updates - on Comarch's side. The client does not have physical access to the database.
Enterprise Cloud - dedicated infrastructure in Comarch's Data Center with the ability to add custom extensions and deeper integrations. For companies that want the convenience of the cloud but need customizations beyond what Standard Cloud offers.
With a subscription on your own server, the role of the IT partner is the most traditional: maintaining SQL server, Key Manager, backups and updates. With Standard Cloud, the scope of work changes but does not disappear - remote access management, authentication policies on the Comarch gateway, synchronization with local systems (e.g. local Active Directory) and integrations with external platforms such as Baselinker or APIs for e-commerce are added. Enterprise Cloud in practice requires the same work as a local subscription, except that the physical infrastructure is located in Krakow.
In IT outsourcing, which we enter after a client moves to subscription, we shift the emphasis somewhat: more attention is paid to access to the Comarch client panel, monitoring the subscription status, keeping track of payment dates (informationally, not financially) and the integrations the client has already built on their side.
Most common Comarch Optima error messages and their causes
Administrators and IT support teams encounter in Optima a fixed set of messages that seem puzzling at first glance but have documented causes. Each Optima message contains an identifier (ID) that lets you quickly find the vendor documentation - the problem usually is not the diagnosis itself, but that the message appears precisely when there is no time to deal with it. Below are five of the most common messages - each Optima error with an infrastructure-side cause and direction of action.
"Failed to retrieve information about available modules. The program is running in startup version" (ID 29999)
The program has switched to startup mode because it did not retrieve the license from Key Manager. Startup mode has one characteristic limitation: the spread of dates between documents in the database cannot exceed 30 days (60 days in older versions). Above that threshold, saving new documents is blocked and the entire company works in read-only mode. The cause is no communication between Key Manager and Comarch's servers, a wrongly configured virtual key, or an unplugged HASP key.
"System memory in the 'internal' resource pool is not sufficient to execute this query" (ID -2147217900)
The message comes from the SQL Server engine - the internal memory pool could not handle the query. The cause is an outdated version of SQL Server without the latest patches. The solution is to install the latest Service Pack and Cumulative Update for the version of SQL Server you have. The problem typically appears when saving sales documents or cash operations in companies that grow faster than anyone has updated the database engine.
"[DBNETLIB][ConnectionWrite] (send) Connection error" (ID -2147467259)
The message means that the session between the Optima application and the SQL server was broken. The most common causes are an unstable network (wireless, damaged cable, switch issues), a SQL query timeout, or a conflict with the TCP Chimney Offload and RSS functions in the network card. The classic solution in the installations we maintain is to create a SQL alias to the local address (127.0.0.1) and disable network card sleep in the power management policy.
"Incorrect syntax near 'IF'" during database conversion
The error appears during an upgrade to Optima 2026.1+ on older versions of SQL Server. Database conversion in the new version uses T-SQL constructs that SQL Server before 2016 does not support. The solution requires two sides: the Comarch partner stops the database conversion, and the IT department migrates the database engine to SQL Server 2019 or newer - migrating only to version 2016 does not make sense, because its extended support ends in July 2026. Only after the SQL upgrade can the conversion be safely retried. Trying to skip this step and "force" the update ends with the database in an inconsistent state and requiring restoration from backup.
"The ALTER TABLE statement conflicted with the FOREIGN KEY constraint"
Database conversion stops at a foreign key conflict - the schema of the new version does not match the existing data in the database (classic example: table CDN.TypNieobecKartaPracy and constraint FK_TNBTnkLink). The cause is data that was allowed in previous versions but violates referential integrity in the new schema. The solution is to run a repair script on the database - in practice, you need to contact Comarch Support or the Comarch partner who will provide the script. Do not try to modify constraints manually without this script.
FAQ - the most common questions about infrastructure for Comarch ERP Optima
When to review the infrastructure for Optima
A few symptoms that occur most often for customers using Comarch ERP Optima:
Login to Optima takes a very long time, usually for local reasons: unstable network between workstations and SQL server, slow name resolution (DNS/hosts), network card conflicts with TCP Chimney, or simply an underperforming SQL engine.
The database in SQL Express is approaching 10 GB, and no one has planned migration to Standard.
The last Optima update ended with an error, restoration took the whole day, and the backup turned out to be two months old.
Additional Comarch HRM or DMS databases are not covered by the backup schedule - the schedule was once set up for Optima alone and no one updated it after additional modules were implemented.
If you recognize any of these symptoms, now is the time to review the infrastructure calmly before the next update. Helpwise IT maintains IT infrastructure for Comarch ERP Optima for companies that do not want accounting to stop when something goes wrong in the infrastructure. We work in a fixed subscription model, in which routine operational tasks are included - IT support, IT assistance and monitoring at one price, without adding a fee for each technician visit. We leave the implementation of Optima itself to your Comarch partner - with whom we are happy to cooperate. Tell us where your Optima infrastructure stands - we will advise where to start.
----
Sources
[1] Comarch, Hardware and software requirements for Comarch ERP Optima, knowledge base 2026 - https://pomoc.comarch.pl/optima/pl/2026/dokumentacja/wymagania-sprzetowe-i-programowe/
[2] Comarch, Hardware requirements for Comarch ERP Optima, product page - https://www.comarch.pl/erp/comarch-optima/informacje-dodatkowe/wymagania-sprzetowe/
[3] Comarch, Instructions for Comarch ERP Key Manager, Comarch ERP Optima knowledge base - https://pomoc.comarch.pl/optima/pl/2018/index.php/dokumentacja/instrukcja-menadzer-kluczy/
[4] Comarch, Comparison of models: Subscription, Standard Cloud, Enterprise Cloud, 2026 - https://www.comarch.pl/erp/comarch-optima/porownanie-modeli-subskrypcja-czy-chmura/