The on-premise eOffice roadmap: from survey to go-live

eOffice is not software you "sign up" for and start using. It runs on your organization's infrastructure, integrates deeply with what you already have, and is customized to your real operations. That means deployment is a project, not a checkout. This piece maps the real roadmap — from the first survey to go-live, and through the operating phase that follows — so you know what you're stepping into: what each phase produces, who needs to be in the room, how long it typically takes, and where the risks sit.

This is also the fundamental difference between a system on your own infrastructure and a shared subscription service. If you are weighing the two directions, comparing on-premise eOffice and SaaS and the criteria for choosing eOffice software will help you decide before you walk into the roadmap below.

Overview: 3–6 months, sequential phases

A typical Tetra eOffice on-premise deployment takes 3–6 months or more, depending on integration depth and organizational readiness. There is no fixed number because no two organizations are alike: existing systems, approval processes, infrastructure, digital signatures — each changes the equation.

Read this roadmap not as a rigid calendar but as a series of gates. Each phase has a clear output, and you should only step through once that output is approved. Skipping a gate "to save time" almost always comes back with interest in a later phase. Below is each phase, with its deliverables, the people involved, a reference duration, and the risks that tend to show up.

Phase 1 — Consultation and current-state survey

Before discussing features, we need to understand where you are. This phase answers three core questions.

• What is the real expectation? Going paperless, cutting approval time, or meeting document-format compliance? These three goals lead to three different builds.
• What are you running? Does the organization already have Microsoft 365? Whose digital-signature service? Which HR or accounting systems need to connect?
• How do you operate? Incoming/outgoing document flows, who approves, how many levels, what exceptions — including the exceptions nobody mentions day to day but that appear a few times a month.

Deliverable. A current-state survey report: business-flow diagrams, a catalog of systems to integrate, the state of infrastructure and digital signatures, and an agreed list of prioritized goals.

Who's involved. On the vendor side, a consultant and a solution architect; on your side, records clerks, representatives of the departments that approve most, and whoever owns infrastructure. Without the voice of the people who actually do the work, the survey only looks good on paper.

Reference duration. Roughly one to three weeks, depending on scale and number of departments.

Risk. This phase decides most of the outcome. A shallow survey gets paid for in month four, when an approval branch that was never described surfaces. The biggest risk is "shadow" processes — the way work is really done, which differs from what the written rules say.

Phase 2 — Design and scope

From the survey, two things get fixed.

Feature groups. Document management, approval workflows (BPM), digital signing, HR interoperability — you don't have to do everything at once. Phasing delivers value earlier and reduces risk: phase 1 should be the core the whole organization uses daily, with the distinctive parts pushed to later phases.

Deployment model. This is where many organizations are unclear:

• If you already have Microsoft 365 (common in large enterprises), the fastest path is to leverage it: sign-in via Entra ID (SSO), file storage on SharePoint. Staff use familiar accounts and learn nothing new.
• If you don't use M365, or want full autonomy, eOffice can run independently on open-source alternatives — independent authentication (Authentik) and S3-compatible object storage (MinIO). No lock-in to any vendor.

What both share: your operational data always sits on your infrastructure. That's what on-premise means.

Deliverable. A solution design document and a fixed phase-1 scope: the feature list, the deployment model, the approval-flow diagrams to be built, and the integration points to prepare.

Who's involved. A solution architect and your decision-making point of contact. This phase needs someone with the authority to sign off, or scope will drift.

Reference duration. Roughly two to four weeks.

Risk. Uncontrolled scope creep. Every department wants one more branch, and phase 1 balloons to the point it never goes live. The discipline of fixing scope here is what carries the project to the finish.

Phase 3 — Infrastructure and integration prep

The technical phase, and where schedules usually stall because of third-party dependencies.

• Server infrastructure — prepare servers or VMs, networking, backups, TLS certificates.
• M365 admin rights (if going the M365 route) — an administrator must create the app and grant tokens. It sounds small but often waits the longest, because it goes through IT and sometimes a security review too.
• Digital signatures — valid e-signing requires integrating the signature service your organization uses. Tetra eOffice supports VNPT SmartCA, Viettel MySign and MobiFone HSM; identify early which service the organization runs so the certificates and configuration can be prepared accordingly.
• Existing systems — connect to HR, accounting or internal portals where interoperability is needed. Note: HR-data interoperability is a separate integration with the HRMS, not a built-in module you simply switch on.

Deliverable. An infrastructure environment ready for installation, integration accounts and tokens granted, digital-signature certificates working.

Who's involved. Your infrastructure/IT team is the lead here, working with the vendor's deployment engineers and third parties (the signature provider, the M365 administrator).

Reference duration. Roughly two to six weeks, most of it waiting on third parties rather than active work.

Risk. Every external dependency is a waiting point. A slow M365 token, a signature certificate stuck in procedure, a server not yet provisioned — any link can drag the whole phase. The way to reduce this is to kick off all these requests in parallel from the start, not sequentially.

Phase 4 — Deployment, customization and testing

Install, configure approval flows to match the surveyed process, customize forms and document formats, then test with your organization's real data. This phase needs your people: only insiders know what a "correct" official document looks like — from where the seal sits to how the reference number is assigned.

Testing should follow real business scenarios, not a few random clicks. Take the hardest documents, the most tangled approval branches, run the full cycle from creation to signing to issuance, then compare the result against how it is done today.

Deliverable. A system configured to match the business, a test record with the scenarios that were run, and a list of adjustments before go-live.

Who's involved. The vendor's deployment engineers, alongside your key users — usually records clerks and a few representative approvers.

Reference duration. Roughly three to eight weeks, depending on the degree of customization.

Risk. Discovering late that the process described in the survey does not match reality. Testing with real data rather than sample data is the cheapest way to expose that gap before it becomes an incident after go-live.

Phase 5 — Training and go-live

Train by role (clerks, approvers, admins), run in parallel with the old way for a period if needed, then cut over. Running in parallel keeps a fallback while people learn, at the cost of double effort for a short window — weigh it against your organization's risk tolerance.

Deliverable. Role-based guides, completed training sessions, and a system officially receiving live documents.

Who's involved. The vendor's training team and all end users; on your side, a coordinator to gather feedback in the first days.

Reference duration. Training around one to two weeks, plus the optional parallel-run period.

Risk. Resistance to change. Users accustomed to paper may quietly revert to the old way if they are not closely supported in the first week. Being present to resolve friction on the spot is what decides whether the system is actually used.

Phase 6 — Operations and post-go-live support

Go-live is not the finish line. After the system runs live, flows still need tuning based on real feedback, the feature groups deferred to later phases get added, security updates are applied, and backups are checked on a schedule.

Deliverable. A support commitment, an incident intake and handling process, and a plan for the next phases.

Who's involved. The vendor's support team and your administrators. With the on-premise model, the organization needs someone who can monitor the servers and verify backups — if there is no such person and none is being hired, that is a gap to raise back in the design phase.

What makes it fast or slow

In practice, the schedule hinges on three factors — all on the organization's side:

1. Readiness. Whether M365 admins, digital signatures and server infrastructure are available.
2. Degree of customization. The more distinctive the process, the more time to build and test.
3. Number of systems to integrate. Each connection is a dependency and a waiting point.

How to prepare for speed

• Appoint one decision-making point of contact on your side (missing this is the most common cause of delay).
• Gather in advance: current document-flow diagrams, form lists, digital-signature details, M365 admin details (if any).
• Define a realistic phase-1 scope; don't cram everything into one go.
• Kick off third-party dependencies (tokens, certificates, server provisioning) early and in parallel, rather than waiting until the phase that needs them.

Conclusion

Deploying eOffice on-premise is an accompanied project, not a transaction. In return: a system that matches your operations, data that stays on your infrastructure, and no vendor lock-in. It suits corporations, state-owned groups and the public sector — places where distinctive processes, sensitive data and system longevity make autonomy a requirement rather than a preference.

If your organization is considering it, book a consultation so we can survey your current state and sketch a roadmap that fits your reality.