Requirements and choosing the variant
We collect the maker requirements and compare them with what you have. This is where it is decided whether the system stands with you or with the supplier, and what each option really costs.
ERP, warehouse, production, legal, medical or design: each of them drags along a server, a database, licences, backups and links to what you already run. The software maker answers for their program but not for the environment it works in, and that is precisely our part. Beyond industry systems we also run the platforms from company systems, meaning mail, storage and teamwork.
We say this at the start to avoid a misunderstanding: we are not the maker of your ERP or industry system and we will not write a new module in it. We are the party that prepares the environment, moves the data, connects the system to the rest of the company and talks to the supplier when something breaks. In practice this is the role most often left vacant, and without it a deployment stalls between two firms, neither of which feels responsible. In manufacturing plants the planning system is often the thing that stops the line when it fails, so we cover maintaining it separately under IT for manufacturers.
Poland KSeF has stopped being a topic for later. It is now the commonest reason companies open the subject of updating or replacing a system at all.
KSeF 2.0 started on 1 February 2026 and from that date every company receives invoices through the system. The duty to issue them covered the largest taxpayers first and the rest from 1 April 2026, except the smallest, invoicing up to PLN 10,000 gross a month, who have until the end of the year.
The previous version of the system was switched off for good and the FA(2) invoice structure was replaced by FA(3). A program wired to the old interface simply will not send a document, so a version that was compliant a year ago is not compliant now.
We check whether your version supports the new structure, set up the permissions and certificates on the company side, and then walk through issuing and receiving a document on test data before the first real invoice goes out.
One thing takes the pressure off: for 2026 there are no penalties for getting KSeF wrong. That is not a reason to postpone the subject but a window to settle the process calmly, train the accounts team and check what happens when the invoicing system is briefly unreachable. While you are at it, agree who in the company may issue invoices, because that question usually surfaces only at the first problem. Accounting offices have a separate problem, because there the permission is granted in the context of each client's tax number individually; we set it out under IT for accounting offices.
The price of an industry system in the offer is rarely the whole story. Underneath sit a server and a database, and their licensing has thresholds that surprise people on the first invoice.
Licensing SQL Server per core means covering every physical core in the server, with a minimum of four licences for each processor. A machine with two processors of eight cores is sixteen licences, bought in two core packs, regardless of how many people use the system.
Under the access licence model every user or device reaching the database needs a licence, including indirectly. The argument that people only log in to the ERP and not to the database does not reduce that count, and it is one of the commoner findings in an audit.
Windows Server is licensed by cores with a minimum of eight per processor and sixteen per server, plus an access licence for every user. Working over a remote desktop needs further licences for that service, which with a remotely run system can double the cost of entry.
So we work the bill out before the server is bought, not after. Sometimes it turns out that a smaller machine with stronger cores is cheaper in licences than a large one with many weaker ones, and sometimes that the maker hosted version beats your own server room. It is an hour of conversation that can move the budget by tens of thousands of zloty.
Six things that happen around the system and that its maker will not do for you.
We collect the maker requirements and compare them with what you have. This is where it is decided whether the system stands with you or with the supplier, and what each option really costs.
We prepare the machine, the system and the database to the maker requirements, along with monitoring and room for the data to grow. The test environment goes up separately so that updates are not tried out on production.
We count how many licences are really needed for your cores and users, and show where the licensing model changes which hardware pays off. You buy from us or wherever you bought before.
We move the data from the old system and agree what travels in full and what stays in an archive for reference. We always run a trial migration first, because only that shows the real state of the data.
We connect the system with the shop, mail, the bank or the warehouse so that data is not retyped by hand. Usually a file exchange or a few flows is enough, with no separate software to write.
The database of an industry system is usually the most important file in the company. We set up backups together with a restore test, because with an ERP what counts is not that a copy exists but how soon you can work on it again.
What we do not do: we do not develop somebody else software and we do not promise fixes in a module we did not write. With a fault in the system itself we report it to the maker, keep an eye on the deadline and translate their answers into the decisions you have to take. If, on the other hand, the process can be simplified without touching the system, we say so before anybody pays for a new module.
The timing depends on the size of the system, but the order is always the same. The longest part is not the install, it is the data.
We talk to you and to the system supplier, write down the requirements, count the licences and settle who answers for what. That one document saves the most argument later at handover.
We stand up the server, the database and the test environment, install the system and run a trial migration. This is the stage where gaps in the data show up that have to be fixed on your side.
The real migration runs in a window when the company is not working, preceded by a full backup and an agreed moment at which we fall back to the old system if something goes wrong.
Updates go onto the test environment first and onto production only once the people who work in the system confirm it. While there we watch the size of the database and the performance, because both grow quietly.
Every industry has the one system without which it does not work for a single day. Below are the ones we meet most often.
The pages the conversation moves to after the first meeting.
We work with the system you have chosen or already run, because we are not tied to one maker. Our part is the environment, the licences, the data and the links, while the functional configuration of the modules is usually run by the maker own consultant. Those two sides working together is the norm and we build the schedule around it.
First we check with the maker whether a version supporting the new invoice structure exists and what it takes to install it. If no update is planned, the options are replacing the system or using an intermediary that accepts the document and passes it on. Receiving invoices through KSeF has been mandatory for every company since February 2026, so this step cannot be skipped.
The hardware is often the smaller part of the bill compared with the licences. The database is counted by cores with a minimum of four licences per processor, and Windows Server by cores with a minimum of sixteen per server plus access licences for the users. That is why we pick the machine and count the licences together, before you order anything.
Often yes, and that removes part of the licence cost and the care of hardware. What decides is what the system maker allows and how the program copes with delay on the link, which matters with terminals and scanners in a warehouse. We check both options and show the difference in cost over three years.
With a smaller system usually four to six weeks, counting from gathering the requirements to going live. The longest part is preparing the data from the old system rather than the install, which is why we run a trial migration early. We give dates only after seeing the data, because guessing blind ends in slippage.
We install them on the test environment first and ask the people who actually work in the system to check. They reach production after that confirmation, with a full backup and an agreed point of rollback. The rhythm is dull and that is exactly why it works.
No, because we are not its maker and we do not have its code. What we do is gather the evidence, report the case to the supplier, keep an eye on the deadline and explain what their answer means for your work. If a workaround is possible on the environment or the process side, we propose it straight away.
The first meeting takes 30 minutes and commits you to nothing. We will tell you straight whether we can help and what we would propose.
2019 - 2024 Interactive Workspace Ltd. - All rights reserved.