Moving to a new system and migrating data from Excel, Access and accounting software.

02 / 08

Moving from FIBU or OMEGA to POHODA, opening balances included

I can move you from FIBU, OMEGA or another accounting program to POHODA, opening balances included. FIBU and OMEGA are Slovak accounting programs, and I work the same way with other programs too. I export the data from the old program, reshape it into a form POHODA accepts, and after the transfer I prepare control reports your accountant uses to sign off on the balances. I don't keep your books, so your accountant decides which account each item belongs to. My job is to make sure that decision is applied the same way to every record.

The simplest switch is at the start of the accounting period, usually 1 January. POHODA has an agenda for this called Počiatočné stavy účtov (opening account balances), where you enter balances as of the first day of the period. For a mid-year switch there's the Východzie stavy účtov agenda, with balances as of the switch date. STORMWARE, the maker of POHODA, points out in its POHODA manual that you then lack the detail from the earlier part of the period, such as open items, stock movements and customer turnover. So if you can, I recommend switching at the start of the year.

The open items ledger usually takes the most manual work. In POHODA, unpaid invoices from earlier periods are entered with the posting rule Vlastná predkontácia Bez (no posting), on an account with open item tracking switched on and with a transaction date before the start of the period. That way nothing is posted to the general journal twice, and the invoices are carried into the Začiatočné stavy salda agenda. With hundreds of invoices, I generate these records automatically so nobody has to retype them.

For the transfer itself, POHODA offers two routes: XML import, which STORMWARE documents for developers, and importing selected agendas from Access (MDB) and dBase (DBF) files, such as contacts, stock, invoices, bank, cash and the chart of accounts. Fixed assets aren't on the list of agendas that can be imported this way, so I check in advance whether we transfer them through XML or your accountant enters them by hand. This is what I move to POHODA:

• The contact list with company ID (IČO), tax ID and VAT number, addresses and contact details, cleaned of duplicates before the transfer
• The chart of accounts with analytical accounts and cost centres, with a table showing which old account maps to which new one
• Opening balances of balance sheet accounts as of the switch date
• The open items ledger: unpaid issued and received invoices and other receivables and payables, document by document, so they can be matched with payments in POHODA
• Bank account and cash balances
• Stock with item cards, quantities and prices
• Fixed assets with acquisition cost, depreciation to date and net book value, so depreciation carries on without a gap

03 / 08

How I check that the numbers match after the transfer

I don't consider a transfer finished until the control totals match. I run the checks after both the trial run and the live transfer, and you get the results in a spreadsheet your accountant can compare with reports from the old program.

I don't hide a difference by rounding. I trace each one down to a specific document, so you know whether it came from the transfer or was already in the old program's data. These are the main checks:

• Trial balance: the debit and credit turnover in the Total row must be equal, which is also the check STORMWARE recommends
• The balance of every account in POHODA against the old program's balance on the same date
• Open items by business partner: the total of open invoices for each customer and supplier must match the old program's ledger
• Stock: quantity and value by warehouse and by item
• Fixed assets: acquisition cost, accumulated depreciation and net book value by asset card
• Record counts: how many companies, invoices and stock cards left the old system and how many arrived in the new one
• Contacts: the same company ID under two names, invalid IDs and broken accented characters from old text encodings

04 / 08

Moving off Excel, Access or a legacy PHP application

When you move off your own spreadsheets or an old application, the hardest part is that nobody has checked the data for years. In Excel the same customer is spelled three different ways, the date column occasionally says "around March", and Access still holds orders for products that no longer exist. So before the transfer I clean the data and show you the questionable records in a list.

A language model helps with the cleanup. It suggests, for example, that two entries with the same company ID and slightly different names are the same company, or that a line saying "mat. purchase" belongs under materials. Fixed rules then check IDs and formats, and someone from your company who knows the data decides the unclear cases. I use models through business APIs whose providers, under their terms, don't use the data for training by default, and where possible the data stays in the EU.

I don't fix or maintain the old application. With a PHP application, I work out from its database and screens everything it does, build a new system and move the data into it. I also looked after databases and connected systems between departments at U.S. Steel Košice, where I was the only developer in my department. If you're moving from Access straight to POHODA, POHODA can read some agendas from MDB files, so sometimes the data only needs to be prepared properly.

With a new system, the old tool keeps running alongside until the new one is fully up. People don't lose work in progress, and they try the new system on real jobs. If you then want incoming invoices to reach your accounting software without retyping, see invoice data extraction.

05 / 08

The steps from export to go-live

Every move follows the same steps. With an accounting program they're shorter, with an old application longer, because I'm building the new system alongside the transfer. I write the whole transfer as a script, so I can rerun it as many times as needed, and the live transfer is simply the last run of the same procedure.

• Export: I get everything I can out of the old system, ideally straight from the database. If the program has no usable export, I use its print reports saved to a file.
• Mapping: together we decide where each field goes, which old account matches which new one, and what doesn't get moved at all. The result is a table you sign off on.
• Trial run: I transfer the data into a test copy that we can throw away and refill at any time.
• Checks: I run the control totals and you or your accountant go through the differences. I repeat the trial run until everything matches.
• Running in parallel: with a new system, people work in both for a while so you can compare results on real work.
• Go-live on a set date: on the agreed day we switch the old system to read-only, I transfer the final state, and from then on everyone works only in the new one.

06 / 08

People's habits: shortcuts, number series and print layouts

People who have used an old program for years have habits their speed depends on. The warehouse worker knows product codes by heart, the person doing invoices types customer abbreviations, and customers expect a delivery note in the layout they're used to. So before the move I write down what people do every day, and we agree on what to keep.

Not everything can be kept, and not everything is worth keeping. If we'd be carrying something over out of habit that nobody needs, I'll tell you. I train people on your own data, so in the new system they immediately see their customers and their jobs. Here's what can usually be kept:

• I transfer product codes, customer abbreviations and order numbers unchanged, so nobody has to learn them again
• Number series for invoices and other documents continue from the last number in the old system
• I can build print layouts such as the invoice, delivery note or production order in the new system so they look the way they do now. POHODA has its own editor for print reports, REPORT Designer.
• In a custom system, I set keyboard shortcuts and field order to match the old one. In an off-the-shelf program like POHODA, people adapt to the way it works.
• Excel reports that management used to put together by hand are replaced by reports in the new system or by an export in the same format

07 / 08

When to go straight to STORMWARE or your software vendor

Sometimes you don't need me. If you're moving to POHODA at the start of the year, have a few dozen open invoices and a small contact list, your accountant can enter the opening balances by hand and STORMWARE support will help you set up the program. When you're moving between versions or products from the same vendor, for example within KROS or Money, ask their support first what they can transfer themselves.

It makes sense to call me when at least one of these applies:

• There's so much data that entering it by hand would take days, for example hundreds of open invoices or thousands of stock cards
• The old program has no export the new program can read, or its vendor no longer supports it
• The data needs cleaning, merging from several sources or recalculating before the transfer
• Along with the move, you want to connect other systems, such as an online store, a warehouse system or a CRM. I cover that on the system integration page.
• You're moving off Excel or Access to a new system that I'm building for you at the same time

08 / 08

How much moving to a new system costs

The consultation is free, and after the first call you get a specific price and date. I split the quote into parts, so you can see what the data transfer costs, what the checks cost and what a new system would cost, if you need one.

Transferring data into an off-the-shelf program, for example from OMEGA to POHODA, takes a few days of work, and I price it much like automating a single process, which usually starts at €500. A new system that a company runs on every day is priced by scope, and migrating the old data is one part of it. Running a new system on my accounts, meaning hosting, backups and updates, comes to tens of euros up to a low few hundred euros a month.

Once you approve the quote or some of its parts, I build a free prototype, for a migration including a trial transfer of part of your data, so you can check that it will work before you make the final decision. You pay 20% when you order and the rest after handover. I always fix bugs in what I've built for free.

A transfer involves personal data from contact lists or HR records, so before we start we sign a data processing agreement under Article 28 of the GDPR. You'll find the other terms on my About page.