Subiekt GT to nexo: what the migration does to your integration

The Sentence Everyone Reads Past

It sits on InsERT's own page for Subiekt nexo, in the part about bringing data across from the older line: nie ma możliwości przeniesienia dokumentów. There is no way to transfer documents.

Five words, no asterisk, published by the vendor. And in every migration conversation I've had with a company running an integration on Subiekt GT, that sentence had either not been read at all or had been read as a formality — something that surely comes with a workaround, or that applies to somebody with a messier database.

It doesn't. It's the central fact of the whole exercise, and once you take it seriously the project changes shape. What was scheduled as a weekend turns into something with a before, an after, and a permanent middle.

This is the migration half of the developer's guide to Sfera in Subiekt nexo, written for the same reader: whoever has to keep an integration alive across the move. Same rule as always — every claim about what the tooling does comes from InsERT's own materials, because in this corner of the market a confident guess costs somebody a production weekend.

What Actually Crosses

The transfer isn't a utility you run whenever you like. It's a stage of creating a new podmiot in the Kreator wdrożeniowy. Once, at the beginning. It is not a sync you repeat next month when somebody notices what's missing.

Four stages: point it at the source database and the server, export into intermediate exchange files, choose the import scope, then import with validity checks and an error report.

What comes through:

• the item catalogue — goods, services, sets, returnable packaging
• the contractor directory
• the dictionaries: groups, characteristics, cash registers, warehouses, countries, users, discounts, VAT rates, payment forms, currencies, voivodeships, bank accounts
• entity data and parameters
• price lists and pricing
• opening balances of cash registers and bank accounts
• inventory
• unsettled receivables and payables — and only the part still open

Stop on that last line. It's the only piece of transactional reality that crosses the gap. Everything above it is master data: things that describe the business rather than things that happened to it. You arrive in nexo knowing who your customers are, what you sell and what you're owed. You arrive knowing nothing about how any of it came to be.

Two small ones people trip on: user passwords don't transfer, and when contractor records are merged, duplicates are recognised by symbol. Hold onto that second one. It comes back later as the most expensive sentence in this article.

The History Is a Window, Not a Copy

Here's where most write-ups get vague, and where the money is.

You don't lose access to the old documents. Subiekt nexo can show them, through what InsERT calls dane archiwalne, and you can issue corrections and returns against them. Sounds like the problem is solved.

It isn't solved. It's relocated. Those records are still sitting in the Subiekt GT database, and nexo is reading them where they lie. InsERT is explicit about the consequence: delete the GT database and zostaną usunięte one również w programie Subiekt nexo — they disappear from nexo too. Documents added in GT after the migration flow into that same archive, which tells you the link is live rather than a one-off snapshot.

So the honest description of a GT-to-nexo migration is this: you now run two databases, and one of them is load-bearing forever. Not a legacy box you decommission once the audit window closes. A dependency of the system you just bought.

That has a budget line — hosting, SQL Server licensing, backups, and someone who remembers the thing exists when the machine it lives on gets rebuilt in 2029. Nobody puts it in the estimate. The estimate was written against a word like migration, which implies an ending.

Why the Integrator Pages Say Something Different

Search for this and you'll find vendors advertising that they move everything, complete document history included, one to three working days. That contradicts the vendor's own sentence at the top of this article. Both claims are sitting on the public internet, so let's settle it rather than step around it.

Three explanations, in decreasing order of how often I meet them. First, and by far the most common: everything means the archive mechanism above plus the opening balance, described generously. Second: somebody built a custom import outside the wizard, writing historical records into nexo as documents or into custom fields — possible, chargeable, and it does not reproduce the original cost calculations, which is precisely why the wizard refuses in the first place. Third: the copy was written by someone who has never done one.

You don't need to guess which. Ask one question: after the migration, can I delete the Subiekt GT database? The answer sorts all three in a second, and it's the answer your architecture depends on anyway.

The Identifier Problem Nobody Budgets

Now the part that belongs to you specifically — and the reason I'd rather you read this before the project than halfway through it.

The new database issues its own identifiers. Every system outside Subiekt that stored a GT id is, the morning after cutover, pointing at nothing. Or worse, at something. The B2B portal keeping a product id against each catalogue entry. The shop mapping SKUs to internal ids. The WMS. The reporting warehouse. The order-intake automation. Anything that ever wrote id_towaru into its own tables.

InsERT hands you exactly one bridge: contractors are deduplicated by symbol. Useful — and that is the entire extent of the help. It covers contractors, not products, and it works only as far as the client kept symbols clean, which on a database that's been running since 2014 is an empirical question you want answered before you quote.

So the deliverable is a mapping table, product by product and contractor by contractor, old id to new. Build it from the exchange files during the migration, while both sides are still readable and nothing has moved. Rebuild it afterwards and you're reconciling on names and symbols across two systems that no longer agree — the single most reliable way I know to turn a two-day cutover into a fortnight.

Write it into the migration plan as a named artefact with an owner. Not a task buried in someone's week.

Your Sfera Code Does Not Come With You

I covered this in the nexo guide, so briefly: the connection model is inverted. Sfera in Subiekt GT creates a COM object and attaches to a running subiekt.exe. Sfera in nexo references InsERT's InsERT.Moria.* assemblies from the installation directory and connects to the database directly — and it exists only in the nexo PRO tier, priced per workstation across the installation rather than once, for the developer.

For planning purposes: a rewrite of the connection layer, plus a licensing conversation that happens with the owner rather than with IT. The three-way comparison for integrators has the tier detail if you're scoping.

What survives completely untouched is everything above that layer: the logic deciding what a document should contain. If that logic lives inside your Sfera code, you rewrite all of it. If it lives behind your own interface, you replace one component and the rest never notices the ERP changed underneath.

Same advice I've given about every ERP on this site. This time with a date attached.

The Order I'd Run It In

1. Inventory the couplings first. Every external system, every place a GT identifier is persisted. One day of work, and the only step that makes the rest estimable.
2. Build the mapping table from the exchange files, during the wizard run, not after.
3. Rewrite the connection layer against nexo before cutover, on a test podmiot created from a copy of the GT database. You want your integration working against nexo while GT is still the system of record.
4. Agree the freeze. The opening balance is built from the stocktake as of a moment. Somebody has to stop issuing documents at that moment, and it will not be the warehouse's idea.
5. Reconcile the open settlements by hand on day one. Only the unsettled portion crossed. Whether the number is right is not something the wizard will tell you.
6. Keep the GT database, and write down why, so that in three years nobody reclaims the disk.

Where Automation Helps, and Where It Doesn't

No agent performs this migration. It's a wizard, run once, by a person who accepts the consequences — and anyone selling you AI for that step is selling you something else.

Automation earns its keep on either side of that step. On the way out: reconciliation. Comparing the closing state in GT against the opening state in nexo, item by item and settlement by settlement — a few thousand comparisons nobody enjoys, which is exactly why everybody samples them instead of finishing them. On the way in: keeping the mapping table honest while both systems are still taking changes.

Then there's the third thing, the one that actually pays. The order-intake work I described on Subiekt GT — reading the email, deciding what belongs on the document — crosses the migration without modification, because it never knew which InsERT line was underneath. That isn't luck. That's the design paying for itself on the one day it was built for.

Planning a GT-to-nexo move with an integration hanging off it? Get in touch. An hour spent listing everything that holds a Subiekt id is worth more than any migration quote written off a feature list.