As the name Logo Edge circulates more widely, businesses that have run Tiger or Netsis for years keep asking the same thing: “Do we need to move too, and when?” In that form the question has no clear answer — because it is incompletely framed. A migration decision is not a matter of timing, it is a matter of need. Rather than repeating product features, this article looks at the decision itself and at how a migration is planned.
First, a misunderstanding worth clearing up
Logo Edge is not a different ERP replacing Tiger. It is an umbrella that moves Logo's existing product families onto a next-generation technology base: the Tiger family sits under it as T-Series, the Netsis family as N-Series and the j-Platform family as J-Series. So the subject is not “moving to a new ERP” but “continuing the existing ERP on a next-generation infrastructure”.
That distinction matters in practice, because it stops two very different project sizes from being confused. Moving to an entirely different ERP requires redesigning processes; moving to the next-generation counterpart of the same family is mostly about carrying the existing structure across and letting users settle into a new interface.
We have set out in detail which product family each series corresponds to, how the T-Series Basic, Standard and Enterprise packages differ, and what the PaaS infrastructure brings: Explore the Logo Edge page
The right question: which need calls for this?
“It's new, let's move” is not a reason. An ERP migration — however narrow its scope — means testing, data checks, training and a degree of operational risk. What justifies that cost is a concrete problem the move solves. The question to ask when deciding is this: which difficulty we face today disappears in the new structure?
When a migration makes sense
- Field, warehouse or sales teams genuinely need to reach ERP data from outside the desktop
- Most report requests land on IT or a consultant, and management cannot produce its own reports
- Installation, updates and version management have become a recurring burden for the business
- Growth is pushing user counts or module needs against the limits of the current structure
- A hardware refresh, server move or major version upgrade is already planned — folding the migration into the same window lowers total downtime
When postponing is the better call
To be honest about it: not every Tiger or Netsis user needs to move today. If your current installation carries your processes without friction, none of the needs above has materialised, and the team works efficiently with what it has, forcing a migration brings no concrete benefit.
- A major customisation or integration project has recently been completed and the structure has only just settled
- The team is going through critical staff changes — a migration needs the people who know the system best to be present
- You are on the eve of year-end closing, a stock count period or an expected regulatory change
- The business's priority for the period lies elsewhere: a migration does not go well without management attention
The most underestimated part: customisations and permissions
When migration comes up, the first thing that comes to mind is data transfer — accounts, inventory, accounting records. Yet in an ERP installation used for years, the real accumulation is not in the data but in the structure around it: custom parameters, the user permission matrix, document layouts, custom reports, integrations built with other systems. Most of these were added one at a time over the years in answer to a concrete need, and most are not written down anywhere.
This is where migration projects most often stretch out. If the person who could answer “why was this field defined this way?” has left the business, reproducing that customisation takes analysis. That is why the first step of a migration plan should not be data but inventory: which customisation exists, why, is it still used, and is it moving across?
There is an upside to this too: a migration is a natural opportunity to clear out definitions that accumulated over the years and that nobody uses any more. Reviewing each customisation rather than carrying it across blindly leaves the new structure simpler from the start.
Timing: which periods to avoid
When the migration happens matters as much as how it happens. Period-end closings, annual stock count weeks and the start of a busy season are risky windows: adding system uncertainty when operational load is already high raises the chance of disruption. Where possible, timing it for a relatively quiet period gives both the testing process and users adjusting to the new interface more room.
The four steps of a migration
- Current installation analysis — which product, which modules, how many users; customisations and integrations are mapped
- Series and package decision — the analysis establishes which series and which package fits the business
- Data and customisation transfer — account, inventory and accounting data, plus parameters, permissions and document layouts, move under control
- Testing, training and go-live — the new structure is tested together before go-live, user training is delivered, and support continues afterwards
The package decision is a separate decision
Deciding to move and deciding which package to move to are not the same thing. What separates the T-Series Basic, Standard and Enterprise packages is user capacity and the modules included in the main package — all three share the same base structure, the PaaS infrastructure and the Report Assistant. So the choice is not about picking “the better product” but about looking at your current user count and the modules you actually use.
It is worth not treating this decision as bigger than it is: you can move up a package as requirements grow. Rather than buying a broad package up front “in case we need it later”, starting with the package your current usage calls for is the more reasonable route for most businesses.
If you want to compare what the packages cover and which product corresponds to which series: Compare the Logo Edge packages
How we approach it at iyibir
We treat a Logo Edge migration as a decision process rather than an installation job. We first take inventory of your current setup and tell you plainly whether a migration makes sense for you today — including when it does not. When it does, we establish the series and package decision together and run the transfer, testing, training and go-live steps with a single team.
You can see the scope of our implementation, go-live checks, training and support services here: Explore our services