Enova365 is a system that many of our clients use and that we regularly encounter during audits in newly acquired environments - usually when a company hands over IT support to us. The pattern is usually similar: the company has had enova for several years, the system works, but remote access is slow, nobody is really sure where the backups are, and an update released by the vendor is put off "for later" because the last one ended in hours of stress. Before a failure occurs, the infrastructure for enova is practically invisible - and then it becomes the number one problem.

This text is a practical guide to what the environment under enova365 should look like and which decisions are most often made poorly. We write from the perspective of a company that maintains such environments for clients in an IT outsourcing model - and that itself also works on enova from the accounting and invoicing side.

enova365 architecture - three layers and three interfaces

Enova365 is a three-tier system: database, business logic, user interface. The vendor (Soneta) provides three interfaces to the same database: desktop (classic, Windows Forms, also described as Standard), browser-based (Multi, HTML5 via ASP.NET Core) and mobile (Android and iOS). All three run on the same installation and the same SQL database - they can be used in parallel without duplicating data.

This distinction is important, because most infrastructure decisions concern not "enova" itself, but where we place each of the layers and how users reach them.

SQL Server Express or Standard for enova365 - limits and when you feel them

Enova365 in current versions supports Microsoft SQL Server 2016, 2017, 2019, 2022 and 2025, both in Standard and Express editions. The choice between them is not a technical detail, because SQL Server Express - although free - has hard limits that can hit a growing company at the least expected moment.

Express limitations (in versions up to and including 2022) are as follows:

• single database size: 10 GB (according to current Microsoft documentation, the limit in SQL Server 2025 Express has been raised to 50 GB - this is a recent change, but still a limit)

• buffer pool memory: 1410 MB - regardless of how much RAM the physical server has, SQL will not use more

• CPU usage: 1 socket or 4 cores, whichever comes first

• no SQL Server Agent - meaning no built-in scheduler for automated backups, index maintenance or DBCC CHECKDB

• no advanced HA features (AlwaysOn, mirroring), no Profiler, limited replication scope

For a company that is just starting with enova, with a few operators issuing invoices and accounting handled for one entity - Express can be sufficient. The problem appears in the typical SMB scenario: the number of documents grows, a sales module with warehouse history is added, someone enables DMS with attachments stored in the database, HR keeps the full employment and payroll history. Within 2-3 years the database approaches the limit, and what worked smoothly yesterday starts to choke because SQL does not have enough memory for cache.

The second, less frequently discussed Express problem: the lack of SQL Server Agent means that backups have to be organized externally. In theory, this can be done with a PowerShell script in Windows Task Scheduler or with a third-party tool. In practice - very often it is not done at all, because nobody took care of it during the implementation phase.

From experience: if a company plans to use enova seriously and for several years, it makes more sense to install SQL Server Standard right away (either your own license or the Runtime license that Soneta provides for enova). The licensing cost is spread over years, and later you do not need to perform a migration "under pressure" when the database stops opening.

Why enova365 in desktop mode does not work efficiently over VPN

The pattern we often encounter looks like this: each operator's computer has enova365 installed in desktop version, while the SQL Server itself is running on a server in the server room. In the office, over the local network - it works well. Problems start when employees want to connect from home or from another branch over VPN.

Communication between the desktop client and SQL Server uses the TDS (Tabular Data Stream) protocol, which is not designed for WAN links. It is a so-called "chatty protocol" - opening a window with a document list can generate dozens of round-trips to the server. With a local connection (RTT below 1 ms) you do not notice it. With a VPN connection and 30-40 ms latency - each list opening means several seconds of waiting instead of a fraction of a second. Saving a document, rebuilding a view, print preview - the same. Over longer distances and poor links, the work becomes painful.

On top of that, there is VPN encryption (which adds overhead), connection drops that can leave hanging transactions, and bandwidth - because some views and reports download megabytes of data. You can work like that, but it is not a production-grade solution for the whole company.

The conclusion is simple: the desktop client and SQL Server should see each other over LAN, with latency measured in fractions of milliseconds. If the user is physically far away, we do not bring SQL closer to the user - we bring the user closer to SQL.

Terminal server (RDS) for enova365 - the recommended remote access architecture

The solution that Soneta documents itself and that works well for most installations with distributed users looks like this: in the same network where SQL Server runs, we launch a terminal server (Remote Desktop Services on Windows Server). We install enova365 desktop version on it. Users connect to the terminal server through RDP (Remote Desktop) - from the office, from home, from a branch.

Advantages of this architecture:

First, SQL traffic stays on the LAN. Through RDP, the user sends only the screen image and keyboard input - this is a small amount of traffic that runs smoothly over RDP even with 30-50 ms latency and bandwidth in the range of a few Mb/s. The application communicates with the database over the internal gigabit network, so the perceived performance is the same as if the employee were sitting in the office.

Second, an enova update means updating in one place. There is no need to go to a dozen computers and upgrade the client version - we update once, on the server, and the whole company is already working on the new build.

Third, access control becomes much simpler. We manage enova permissions through roles inside enova itself, but who can log in to the terminal server at all is controlled at the Active Directory level. When an employee leaves, we disable the AD account and the matter is closed - there is no need to worry that someone still has a client installed with saved connection parameters.

Fourth, from a security perspective, RDP through RD Gateway with TLS and MFA (or RDP tunneled through VPN to a dedicated management network) is easier to secure than broadly opening the SQL port on the firewall.

This model - SQL server plus application server plus RDS - is explicitly documented by Soneta as one of the recommended hosting architectures for enova.

Enova365 Multi or desktop version - which one should you choose

Multi version (web-based, HTML5) is an alternative or an addition to the scheme above. It runs on IIS or in ASP.NET Core mode, and users connect to it with a browser - Chrome or Edge. The vendor states that, functionally, Multi provides almost the same as the desktop version, and in current enova releases that is indeed the case.

Where Multi works very well: document approvals by managers, employee dashboards, CRM, travel expense settlements, field sales work, report viewing, mobile work. Everywhere where the session is short and does not require intensive keyboard work in dense forms.

Where the classic version often wins in practice: accounting postings, rapid issuing of document series, mass editing of item cards, advanced configuration. This is not due to functional gaps in Multi, but to user habits and the fact that the classic Windows Forms interface offers very fast keyboard shortcut navigation, which accountants perform reflexively after years of work. Here we should be honest - this is primarily a matter of subjective preference. Some accountants, after moving to Multi, do not want to go back; others are categorically unwilling to change their habits.

Choosing "either-or" is not the right decision. Both interfaces can be run in parallel, on the same database, and each user can be given the tool in which they work most efficiently. Accounting stays on Standard on RDS, the manager logs in through Multi from home, and the salesperson uses the mobile app in the car.

Server separation for enova365 - SQL, application and terminals separately

If we decide to use a terminal server, there is a temptation to put everything on one machine: SQL, application, RDS, domain controller, sometimes also file server and backup. For a microbusiness with a few users, this works. For an SMB with dozens of operators, accounting and a warehouse - it usually ends badly.

The model we recommend for installations with more than a dozen users consists of three separate roles (in practice usually three virtual machines on one or two hosts, but functionally separated):

SQL Server. Dedicated only to the database. It has its own RAM pool, its own disks (preferably SSD in RAID1 or RAID10, with separate volumes for data files, transaction logs and backups). Operating system and SQL updates are planned independently of the rest. It also makes sense to enable Standard Edition here if the company needs it - we pay for cores on only one machine, not on the whole stack.

Application server (enova365 Server). Business logic and - if Multi is used - the browser interface server. In its requirements, Soneta explicitly recommends that the business logic server and the user interface server be on separate machines. In current enova365 versions based on .NET 8, Windows Server 2016 or newer is required, 16 GB of RAM and 4 cores as a starting value.

Terminal server (RDS). A completely different load profile - lots of memory per session, GPU for comfortable work, printer handling, device redirection. The performance of this machine scales with the number of concurrent users. For larger teams, it is worth splitting RDS into a farm with two or three hosts and a session broker.

Why does separating responsibilities pay off even in a small company? Several concrete reasons. Updating SQL Server or restarting it after a security patch does not require kicking users out of the terminals - the sessions remain, only enova is temporarily unavailable. Restarting RDS after an update does not affect business logic, and for a moment, when users are logged out, the rest of the system is still running anyway (for example integrations with banking or e-commerce). SQL Server backups do not compete for disks with user profiles on RDS. If memory becomes the bottleneck, it is immediately obvious on which layer - and that layer can be scaled separately, without having to enlarge the entire monolith.

From a maintenance perspective, this is simply cheaper in the long term, because each failure is contained within its own role and does not drag the others down. We apply the same logic when designing server infrastructure for most clients, regardless of whether the primary workload is enova, a file server or a line-of-business application.

Backup of the enova365 database - policy, retention period and restore tests

Audits at new clients very often show one of the following scenarios:

• The backup exists, but it is stored on the same disk as the database.

• The backup exists, but nobody has checked in a year whether it can actually be restored.

• A "backup" was configured in SQL Express in Windows Task Scheduler, and it fails every other week because the service account changed.

• Backups exist, but they are kept for only 7 days and when the problem comes out a month later (someone deleted documents in December and it was noticed in January), there is nothing to go back to.

• The Enova backup is run from the application, but the .bak file remains local and never reaches an external location.

A sensible modern backup policy for an enova installation looks roughly like this: a full backup every night, differential backups every few hours, transaction log backups for a database in FULL recovery mode (if we care about point-in-time recovery). Backup files are written to a separate volume, and from there - to an external location (NAS in another location, cloud, offsite backup). We adjust the retention period to regulations and real needs - for accounting, a shorter period simply will not hold up. Periodically, once a month or once a quarter, we perform a test restore to a second database and verify that the system starts up. DBCC CHECKDB on a regular schedule, so that we do not wake up with a corrupted database that cannot be restored because the backups have been carrying the corruption for a week already.

It is hard to maintain this kind of discipline without someone who has it in their duties - which is why backup is so often the first thing we fix when we take over IT support for a new company.

enova365 updates and database conversion - how to do it safely

Enova365 is updated regularly - new versions are released every few weeks, and in addition Soneta releases regulatory versions that have to be deployed by a specific deadline (KSeF, tax changes, ZUS, PIT). Each major update requires database conversion - that is, migrating the schema to the new version. Software updates and patch management for enova therefore have a different character than for typical office applications - they cannot be automated unattended.

Conversion is an operation that, for a large database, can take from several dozen minutes to several hours, during which work with the system is not possible. The vendor explicitly states this in release messages such as "this version requires database conversion".

The update process should roughly look like this:

What regularly breaks this process: partner add-ons that do not yet have a version compatible with the new enova; custom modifications made for an older version that need to be updated; lack of a backup "just before" conversion and no rollback path. For larger updates, it is worth performing a trial conversion on a copy of the database in order to measure the time and catch issues before the production window.

In companies where we provide IT support, enova updates and their conversions are simply part of the schedule - the accountant does not have to monitor them alone, and we plan the maintenance window in advance so that it falls outside the declaration submission deadline.

How to recognize a well-maintained enova365 infrastructure

From the perspective of the management of a company using enova, everything we wrote above are technical details that should not have to concern them. The company bought enova to run accounting, sales and warehouse operations, not to have another IT project to supervise.

A well-maintained enova infrastructure looks like this: someone monitors the performance of SQL and the application server before users notice a problem. enova, Windows and SQL Server updates have one coherent schedule and someone is responsible for making sure they happen. Backups are taken, verified, and there is a restore procedure that someone has actually tested. In the event of an incident, there is someone to call and that person has access to the environment and understands how it works. Capacity planning - disks, RAM, SQL licenses - happens before something runs out, not after the fact.

This kind of work can be done in-house, by your own IT department, and in large organizations that is how it happens. In small and medium-sized companies there is usually no one who would have all of this on their plate on top of their other duties - and then it makes sense to outsource it, in an IT outsourcing model. IT support for enova is not something exotic either - it is exactly the same set of tasks (servers, updates, backups, monitoring) performed for any serious business system, just with additional knowledge of Soneta's product specifics.

Most frequently asked questions about enova365 infrastructure (FAQ)

Is SQL Server Express enough to support enova365?

Yes, but only for small installations. SQL Server Express has a database size limit of 10 GB (50 GB in the 2025 version), 1410 MB of memory buffer and can use a maximum of 4 CPU cores. For a microbusiness with a few operators, running one entity and not loading the system with a large document volume, it is more than sufficient. For a growing medium-sized company, the 10 GB limit will be reached within 2-3 years - and then you need to move to SQL Server Standard, preferably before the database physically stops opening.

Which Microsoft SQL Server versions does enova365 support?

Currently supported are SQL Server 2016, 2017, 2019, 2022 and 2025 - both Standard and Express editions. The list is updated by Soneta and older versions (2012, 2014) are gradually being phased out. For new deployments, we recommend the latest stable version of SQL Server that is supported by both the enova vendor and Microsoft.

Does the desktop version of enova365 work over VPN?

Technically yes, but in practice it is not a production solution. The desktop client communicates with SQL Server using the TDS protocol, which generates a very large number of short queries to the database - with VPN latency in the range of 30-40 ms, each list opening, document save or print preview takes several times longer than on LAN. Instead of connecting the user to SQL over VPN, a better pattern is to deploy a terminal server (RDS) in the same network as SQL - then the user connects through RDP, while the database traffic remains local.

Does the web version of enova365 (Multi) have the same functions as the desktop version?

The vendor declares that, functionally, the Multi version corresponds to the desktop version, and in current enova releases that is indeed the case. The differences are mainly ergonomic - in the classic Windows Forms version, keyboard-based work is faster, which is especially appreciated by accountants working with shortcuts. Multi wins where work from any device and short sessions are important (approvals, manager dashboards, CRM). Both interfaces can run simultaneously on the same database.

How long does database conversion take during an enova365 update?

From several dozen minutes to several hours - it depends on the size of the database, the modules used and the performance of the SQL server. For a small database (below 1 GB), conversion is usually a matter of a few minutes. For a large sales database with many years of history and a DMS module, conversion may take 2-4 hours. That is why we schedule it in a maintenance window outside business hours and always perform a full backup before starting.

Do SQL Server, the enova365 application server and the terminal server need to be on separate machines?

For a microbusiness - no. For installations with more than a dozen users - we recommend separation. Separate roles (SQL, application server, RDS) allow independent scaling of each layer, independent maintenance windows, better isolation in case of failure and easier identification of performance bottlenecks. In its technical requirements, Soneta explicitly recommends separate machines for the business logic server and the user interface server.

What should an enova365 database backup look like?

A full backup every night, differential or transaction log backups during the day, files stored in an external location (offsite NAS, cloud), retention period adjusted to regulations - for accounting, 12 months is often a good starting point, although the final period depends on company policy and industry requirements. The key is periodic testing of restore from backup to a second database - a backup that has not been tested is not a backup. In addition, it is worth running regular DBCC CHECKDB so that you do not keep a copy containing a corrupted database.

Do I need a dedicated administrator to maintain enova365?

For a single enova installation in a small company, a full-time administrator is not necessary. What is needed, however, is a person or a company whose duties include: monitoring the SQL server, regular enova and operating system updates, backups and their testing, response to incidents. This can be an internal IT specialist who also supports other systems in the company, or an external team in an IT outsourcing model - in most medium-sized companies the latter option is cheaper and provides better continuity during vacations or staff turnover. The key is that the topic has a specific owner, rather than being left "on the accounting side, where someone knows enova".

Does enova365 require Windows Server on the application server?

It is not a hard requirement - Soneta officially supports running the enova365 application server on both Windows Server and Linux (including in Docker and Kubernetes containers). enova's architecture is based on .NET 8, which is cross-platform. The Linux variant is technically supported, but rarely used in classic SMB deployments - the standard remains Windows Server 2016 or newer, as the best documented, most common among implementation partners and easiest to maintain. We mainly see the Linux application server where the company deliberately moves toward Cloud Native. Regardless of the server platform chosen - the desktop client (Standard version) works only on Windows.

What is the SQL Server Runtime license for enova365?

It is a special SQL Server Standard license that Soneta provides to enova clients at a price lower than the standard Microsoft license, provided that SQL Server is used exclusively to support enova. It is a convenient way to bypass the Express limits without bearing the full cost of a SQL Server Standard license purchased directly from Microsoft. The details of the license terms should be confirmed with an Authorized Soneta Partner.

What our IT support looks like for companies using enova365

At Helpwise IT, we provide IT support for companies that use enova365 as their ERP system. In practice, this means that we take responsibility for the environment - servers, SQL, RDS, backups, updates, incident response - so that from the client's perspective, the only visible thing is that the system works and that when the new KSeF version is released, nobody has to call in a panic about the deadline.

Maintaining enova is not an "extra-cost add-on" for us. Deployments, updates, disk replacement, migration to a new server or preparing the environment for the next branch are included in the fixed IT support fee. We call it "batteries included" - and we treat it as a model that is fair to the client: one contract, predictable budget, and we do not earn money from things breaking.

If you recognize any of the scenarios described above - distributed work over VPN on SQL, a database approaching 10 GB on Express, a backup that nobody has tested for a long time, an update postponed because "the last one went badly" - then this is exactly the moment when it is worth sitting down and reviewing the environment with someone from outside. Whether it ends in full IT support takeover or only one-off IT assistance in organizing the infrastructure - it is usually easier to talk afterwards when the environment is predictable.