You've been running Logo GO for a few years and it worked fine. But something has shifted lately — maybe production planning has become relevant, maybe you've opened a new company, maybe reporting requests now go beyond what GO offers. The question on your mind isn't "GO or Tiger" anymore, because that decision is already made: you need to move to Tiger. The real question is: will your data carry over, how long will it take, and do you have to start from scratch?
Signals that the move is on the table
The decision to move from GO to Tiger usually doesn't come from a single event but from accumulating signals: the system starts to feel tight as user count grows, a need for production planning or recipe management emerges, working across multiple companies or currencies becomes unavoidable, or management reporting outgrows the screens GO offers. We've covered a detailed comparison of these signals elsewhere; here the focus is on what happens after the decision is made.
What happens to your data? You don't start from scratch
The most common worry about the move is that years of accumulated data will be lost, or that everything has to be entered again. That isn't the case: account cards, inventory cards, and historical accounting records move to Tiger through a planned transfer process. Customer and supplier balances, stock movements, and accounting history are transferred to the new system in a controlled way — your business keeps building on what it accumulated in GO, now inside Tiger.
That doesn't mean the data flows over automatically like a copy-paste. Data needs to be cleaned and verified before the transfer — duplicate account cards, incompletely defined stock cards, or inconsistent coding, for example, get corrected during the move. But the result is a transition that preserves history — not a fresh start.
Not everything moves automatically: what may need to be rebuilt
To be honest, not everything in GO carries over to Tiger one-to-one. Some custom reports, forms, and print designs built specifically for GO need to be recreated within Tiger's own reporting and form infrastructure. Similarly, third-party integrations set up with GO — e-commerce, a field sales app, a banking integration — may need to be reconfigured to fit Tiger's integration structure.
User authorization is another point. Role and permission definitions in GO need to be reconsidered for Tiger's broader module structure — who sees which screen, who goes through which approval step needs to be redefined. Skipping these steps and treating the move as purely a "data transfer" job leads to surprise gaps once you're live.
What stages does the transition go through?
A controlled move from GO to Tiger isn't a single setup step — it's a sequence of stages:
- Analysis: Your current GO usage, active modules, and new requirements (production, multiple companies, multiple currencies, etc.) are assessed.
- Preparation: Which modules Tiger will be set up with, and which custom reports or integrations need to be rebuilt, are clarified.
- Test environment: A test environment running with real data is set up so parameters and workflows can be tried against actual scenarios.
- Data migration: Account, inventory, and accounting data is moved in a controlled way first into the test environment, then into production.
- Verification: Migrated data is checked line by line against its GO counterpart for consistency.
- Go-live: Operations begin running through Tiger on an agreed date.
- Training: Users are trained on the new screens and processes — this starts before go-live and continues afterward.
How long these stages take varies by business; it depends on user count, data volume, and how much customization is needed. Rather than committing to a fixed timeline, it's more accurate to plan these stages specifically around your business.
The right timing: which periods to avoid
When you move matters as much as how you move. Period-end closings, annual stock counts, or the run-up to an expected regulatory change are risky windows for a transition — operational load is already high, and adding system uncertainty on top increases the risk of disruption. Where possible, timing the move for a relatively quiet period gives both the testing process and users adjusting to the new system more room.
User training: the most underestimated step
The element most often underestimated in a GO-to-Tiger move is user training. Tiger has a broader module structure than GO; screens, fields, and some workflows change. Training isn't just showing "where the button is" — new approval flows, reporting screens, and the authorization structure need to be properly understood. If training is skipped or rushed, the team ends up using only a small part of what Tiger offers, and a perception forms that "GO was easier" — when the real issue is usually not the system, but a habit that hasn't formed yet.
Not moving is also a valid option
Finally, an honest point worth stating: not every business running GO needs to move to Tiger. If production planning, a multi-company structure, or enterprise-level reporting haven't become a real need, and GO is handling your current processes without friction, forcing the move brings no concrete benefit. A transition makes sense when it answers a real need — not simply because it's the "bigger product."
At iyibir, we evaluate both the decision to move from GO to Tiger and the planning of that move together, based on your business's real data and processes — starting with whether the move is worth making, and if it is, how to go about it.