Implementation

Rolling out our products, and moving what you already run

Implementation at Infivex means two things: putting our own products live inside your environment, and migrating or upgrading the Dynamics estate you already have. Sandbox first, advance notice of every update, and the business running throughout.

What this covers

Being precise about what we implement

The word “implementation” means very different things depending on who is using it, so it is worth stating plainly what it means here.

We implement our own productsSLinkHub, Finly, SLinkHub Screens and Smart Event Manager — into environments that are already running. And we handle migrations and upgrades: legacy or on-premises Dynamics estates moved to current, supported, cloud-hosted versions.

We do not run greenfield implementations of third-party ERP platforms. There is no whole-administration rollout method on offer here for replacing your systems from scratch, because that is not the business we are in. What we are in is development and support within Microsoft Dynamics, and the deployment of the products we build ourselves.

Saying that early saves everyone a wasted quarter. If a full replacement genuinely is what you need, we will tell you at the first conversation rather than the third — and an scoping conversation is usually the cleanest way to establish whether it is.

What a rollout looks like

Into a live environment, without stopping it

Our products go into systems that are already carrying real work, which shapes everything about how a rollout is run.

  • Assessment of what exists. Versions, extensions, integrations and customizations are inventoried before anything is installed, so nothing gets a surprise.
  • Sandbox before production. The configuration is proven against a sandbox environment with real data first. Production is never the place where something is tried for the first time.
  • Configuration, not a rebuild. Our products are designed to install alongside what you run — a thin extension in the ERP, with the heavy lifting in the platform behind it.
  • Training before cut-over. People are prepared in advance, so day one is a new screen rather than a new job.
  • Stabilization, then support. Monitoring and adjustment in the weeks after go-live, transitioning into SLA-backed support.
A woman standing at the head of a meeting table addressing four seated colleagues, with a cork board covered in sticky notes on the wall behind her
Our products

What we put live

Four products, each built by us and each deployed by the same team that develops it.

Migrations & upgrades

In-depth assessment, then a clear roadmap

A migration starts with a comprehensive assessment of your current environment, followed by a project plan built around your operation rather than a template.

Comprehensive assessment

We examine what you run today: modules in use, customizations, integrations, data volumes and quality, and the processes that depend on each. Nothing gets migrated that nobody has looked at.

Customized project plan

Sequence, dependencies, cut-over timing and what happens to each piece of legacy functionality — set out before anything moves.

Data and process mapping

We decide together what moves, what is transformed and what is archived rather than carried forward — because a migration is the one honest chance to leave bad data behind.

Sandbox build and testing

The target environment is built and tested in a sandbox with real data, so problems surface where they cost nothing to fix.

Cut-over and go-live

A planned switch with defined checkpoints, a rollback position and staffing arranged for the first live days.

Stabilization and aftercare

Monitoring and adjustment in the weeks after go-live, transitioning into ongoing SLA-backed support.

Proactive update strategy

Key aspects of our update approach

Cloud platforms update on their own schedule. The difference between that being routine and being disruptive is entirely in the preparation.

📢

Advance communication

You are notified of upcoming updates before they arrive, with a clear description of what changes and who in your organization is likely to notice it.

📅

Strategic planning

Updates are tested in sandbox environments before production, and scheduled around your operational calendar rather than dropped into month-end.

🔗

Extension compatibility checks

We continuously monitor extensions, integrations and customizations for version compatibility, so a platform release never quietly breaks something you depend on.

Together these practices significantly reduce the risk of unexpected downtime while maintaining digital security and continuity.

Business continuity

The business keeps running throughout

  • Nothing untested reaches production. Sandbox environments carry the risk so your live system does not.
  • A defined cut-over, not a leap. Checkpoints, responsibilities and a fallback position are agreed before the switch.
  • Staged where possible. Where the scope allows, we move in phases so that no single moment carries the whole risk.
  • Security maintained end to end. Access control and data handling are part of the plan, not an afterthought once everything works.
  • People prepared in advance. Training happens before cut-over, so the first live week is about volume rather than about learning.

How we run it

Pre-production testing
Sandbox
Update notice
In advance
Extension compatibility
Monitored
Rollback position
Defined
After go-live
SLA-backed
Business Central Dynamics NAV BC - On Premise Finance & Operations Azure
Questions

Implementation FAQ

No. Greenfield implementation of a third-party ERP platform is outside what we offer. We develop and support within Microsoft Dynamics, we implement our own products, and we migrate or upgrade environments that already exist. If a full replacement is genuinely what you need, we will say so early rather than take the work.

Technically, a great deal. Practically, you should not bring all of it. During data mapping we separate what the new environment genuinely needs from what is better preserved as an archive, so you do not migrate a decade of accumulated errors along with the useful records.

Each one is assessed during the initial analysis. Many legacy customizations exist because the old version lacked something that is now standard, in which case they simply disappear. The rest are rebuilt as supported extensions — see development.

Cut-over is planned to fall outside your busiest periods and is preceded by a sandbox rehearsal. The exact window depends on data volume and scope, and it is defined in the project plan rather than discovered on the day.

Usually not, and that is deliberate. SLinkHub has interfaces for Dynamics NAV 2018 and Business Central - On Premise alongside current Business Central, so an older environment can meet its e-invoicing obligations without a migration being forced on it by a compliance date. Modernising then becomes a decision you make on business grounds.

Explore the possibilities

Tell us which Dynamics versions you run and what you are trying to put live. That is usually enough for us to describe exactly what your rollout would involve.