Skip to content
SynapseTel CloudService status

Book a 30-minute call

Scheduling is handled by Calendly, whose privacy policy applies to what you enter. Open in Calendly

How we work

How we enter, modernize and hand over regulated estates.

Every engagement runs inside your repositories, behind your CI gates and your reviewers’ approval, so your team can audit every change we ship and run it without us.

We start with read-only diagnostic access, deliver through deterministic CI/CD admission gates with a person approving every merge, and leave every runbook in your repositories, so you can run what we build without vendor lock-in.

Diagnostic onboarding
Read-only access only (STC-ONB-01), with an offline-export fallback
Delivery unit
Paired principal pod: a T1 telecom and hybrid infrastructure lead and a T2/T3 DevSecOps, private MCP and application lead
Entry point
2-week Assessment Sprint: $14,500 fixed, credited in full when you sign an annual agreement within 30 days
Start with a 2-week assessmentSee engagement pricing

Onboarding protocol · STC-ONB-01

No production write access on Day 1, and no wasted sprint days.

We ask for read-only access within three business days of signature. The ten-day sprint clock starts only when a 15-minute connectivity check passes. If your firewall or VPN team needs more time, we can begin from offline exports instead of waiting.

LayerLive read-only scopeOffline fallback
T1 · Ericsson OSS-RC and ENMAn ENM role limited to read operations: cmedit get and read-only AMOS/moshell inspection, with set, create, delete and action not granted. Read access to REST NBI, SNMPv3, VES and Kafka collector configuration.Node and release inventory exports, cmedit parameter dumps and redacted northbound/southbound alarm schemas.
T1 · Red Hat OpenShift and KubernetesThe cluster-reader role, or namespace view plus read access to SecurityContextConstraints, StorageClasses, Nodes, ClusterOperators and NetworkAttachmentDefinitions, to verify restricted-v2 SCCs, project-admin boundaries and Multus/SR-IOV networking.A must-gather diagnostic bundle, ClusterVersion upgrade history and a Prometheus snapshot.
T1 · VMware vSphere, vSAN and KubeVirtThe built-in vSphere Read-only role plus Storage Views › View for vSAN SPBM policies, and read access to Red Hat MTV migration plans.A current RVTools export (.xlsx), a vSAN performance diagnostics snapshot and VLAN/BGP trunking tables.
T2 and T3 · GitLab CI, Argo CD, private MCP and CAMARA portalsGitLab Reporter or GitHub Read, Argo CD role:readonly, Vault/ESO path metadata only (never secret values), and non-production CAMARA (QoD, SIM Swap, Device Location), NEF and SCEF schemas.Redacted .gitlab-ci.yml, Helm/Kustomize charts, OPA/Kyverno policies and OpenAPI 3.x specifications.
  • Sprint accounts that expire automatically after 15 days
  • No extraction of subscriber PII or CPNI
  • Mutual NDA under Florida law before any access

How we start

You do not need a six-month RFP to find out what is breaking.

Every T1, T2 and T3 engagement begins with a bounded 2-week Assessment Sprint ($14,500 fixed fee), 100% credited toward an annual retainer or managed agreement when you continue within 30 days.

  1. Days 1–3

    Boundary and topology read

    Read-only inspection of ENM/OSS mediation, OpenShift SCCs, vSAN storage baselines and CI/CD change logs.

  2. Days 4–6

    Failure and blast-radius map

    Cross-layer handoff risks, single points of failure, and security and compliance gaps.

  3. Days 7–9

    Target architecture (.mmd) and wave order

    Low-level target topology in Mermaid source, a wave-by-wave migration sequence and rollback criteria for each wave.

  4. Day 10

    Executive and principal readout

    The full engineering handoff package and a fixed-scope backlog, ready for your own team or our paired principal pod.

  1. Assessment Sprint$14,500 fixed · 2 weeks · 100% credited on annual conversion

  2. Platform Retainer$24,000/month or $240,000/year · paired principal pod · 2 months free on annual

  3. Managed OrchestrationFrom $34,500/month · 24/7 emergency on-call with named principal engineers

Request an architecture reviewCompare engagement tiers and pricing

Phase 2 delivery

How the paired principal pod ships after the sprint

The Platform Retainer ($24,000/month, or $240,000/year at an effective $20,000/month) and Managed Orchestration (from $34,500/month) run on the same pod and the same change path.

  1. 01

    Two principals across all three layers

    Every retainer pairs a lead telecom and hybrid infrastructure architect (T1) with a lead DevSecOps, private MCP and application engineer (T2/T3), providing 100 to 120 combined principal hours a month.

  2. 02

    Two-week sprints in your repositories

    One active modernization workstream at a time. Every OpenTofu/Terraform module, restricted-v2 Helm chart, ENM script and Next.js portal component ships as a merge request in your Git repositories.

  3. 03

    Deterministic gates and private MCP

    Schema-restricted, read-scoped MCP tooling on self-hosted OpenShift AI or vLLM inside your perimeter drafts readiness diffs. GitLab CI stages (Trivy, Syft SBOM, Cosign, OPA/Kyverno) and your reviewers approve every production merge before Argo CD reconciles it.

  4. 04

    Handover by design

    Runbooks are tested with your engineers before cutover. Take operations in-house at any milestone, with 30 days’ notice on monthly plans, or move to 24/7 Managed Orchestration with a contractual 99.9% or 99.99% availability SLA.

A clear path to ongoing operations

Review the work, deliverables and approval at each stage.

Choose a delivery stage

Discovery and dependency audit (weeks 1–2)

We inventory releases, vSphere/vSAN dependencies, cluster constraints and OSS/BSS interfaces. The assessment records failure domains, compatibility gaps and the systems affected by a change.

What you receive
An assessment summary with findings, risks, and proposed scope.
Before moving forward
Confirm priorities, access, and the boundaries of the engagement.

Target architecture and cutover plan

We produce the target design, dependency graph and cutover runbook, with validation steps, stop conditions and recovery owners for each migration wave.

What you receive
A target architecture, change sequence, and acceptance plan.
Before moving forward
Agree the design, acceptance criteria, and change authority.

Build and pipeline wiring

Changes move through your repositories and approval process. We test representative FM/CM/PM interfaces, workloads or API actions and record the results against the acceptance plan.

What you receive
Implemented changes, test evidence, and an exception record.
Before moving forward
Review the evidence and decide how any exceptions will be handled.

Operate and assure: transfer or managed

Your team receives configuration records, runbooks and recovery evidence. Ongoing support specifies covered systems, escalation channels and the engineer responsible for each service boundary.

What you receive
Support records and documentation defined in your scope.
Before moving forward
Confirm operational ownership and any remaining follow-up actions.

Delivery standards and sample checklists

Use our sample checklists to scope work and review deliverables. Adapt them to your environment. They are illustrative, not customer results, vendor-certified procedures or executable production instructions.

How to read our guidance and samples

Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

Technology names describe the environments we work in. They do not imply vendor partnership, certification or authorization. Vendor licenses and support entitlements remain yours; our engineering assistance does not replace them.

Support hours, emergency coverage and response, restoration and resolution targets are stated beside each engagement option and in your agreement. Read them there rather than in a general note.

Jump to a deliverable

Sample deliverable

Ericsson OSS / ENM change plan

A change plan connecting compatibility checks, acceptance owners, and recovery decisions.

Download .md template
Scope
Releases, interfaces, maintenance window, and change owner.
Checks and review
  • Verify compatibility, access, and backups.
  • Agree stop conditions and recovery decisions.
Acceptance
Checks recorded. Change and recovery approved by the named owner.
View full worksheet: Ericsson OSS / ENM change plan

Use these fields to record the environment, acceptance criteria, evidence, and decisions for the agreed engagement.

Prerequisites

Record source and target releases, deployment type, node mix, supported upgrade path and vendor support entitlement. Name the change owner and maintenance window.

Checks and review

  1. Confirm prerequisites, backup integrity and access. List interface, alarm, configuration and performance checks with expected results and an acceptance owner.
  2. Define stop conditions, recovery steps and who can authorize them. Record test evidence, exceptions and operator handover before closing the change.

Illustrative expected result: Compatibility and interface checks recorded; change and recovery decisions approved by the named owner.

Complete for the agreed engagement

Environment / release / date

Accountable owner

Expected result / acceptance threshold
Complete for the agreed engagement
Observed result / evidence reference
Complete for the agreed engagement
Exception / decision / follow-up owner
Complete for the agreed engagement

Sample deliverable

Kubernetes / OpenShift readiness checklist

A readiness review covering platform dependencies, workload checks, and measured recovery.

Download .md template
Scope
Clusters, workloads, owners, and platform dependencies.
Checks and review
  • Review access, capacity, policy, and observability.
  • Test workload recovery against agreed objectives.
Acceptance
Platform and workload evidence recorded; recovery meets the agreed objectives.
View full worksheet: Kubernetes / OpenShift readiness checklist

Use these fields to record the environment, acceptance criteria, evidence, and decisions for the agreed engagement.

Prerequisites

Inventory clusters, versions, Operators, workloads, network and storage dependencies. Check lifecycle compatibility and identify application owners.

Checks and review

  1. Review identity, RBAC, secrets, policy, delivery pipelines, capacity and observability. Test representative workloads and document unresolved risks.
  2. Rehearse backup restoration and workload recovery in an agreed test environment. Record measured recovery results against agreed objectives, upgrade checks and handover ownership.

Illustrative expected result: Platform and application restore evidence recorded separately; measured recovery meets the agreed objectives.

Complete for the agreed engagement

Environment / release / date

Accountable owner

Expected result / acceptance threshold
Complete for the agreed engagement
Observed result / evidence reference
Complete for the agreed engagement
Exception / decision / follow-up owner
Complete for the agreed engagement

Sample deliverable

AI workflow evaluation report

An evaluation record connecting baseline performance, test cases, and human approval.

Download .md template
Scope
The workflow, approved data, permitted actions, and baseline.
Checks and review
  • Test normal, adversarial, and failure cases.
  • Verify human approvals, audit records, and manual fallback.
Acceptance
Pilot results reviewed against the baseline before wider access.
View full worksheet: AI workflow evaluation report

Use these fields to record the environment, acceptance criteria, evidence, and decisions for the agreed engagement.

Prerequisites

Describe the process, approved data sources and permitted actions. Capture baseline cycle time, error rate and human review effort; document permissions and approval boundaries.

Checks and review

  1. Evaluate representative and adversarial cases: missing data, incorrect model output, connector failure, duplicate events and attempted instruction injection. Record outcomes and reviewer decisions.
  2. Agree acceptance thresholds and cost limits. Verify manual fallback, audit records, exception routing and ownership; compare pilot results with the baseline before widening access.

Illustrative expected result: Evaluation outcomes compared with the baseline; approvals, exception routing and manual fallback demonstrated.

Complete for the agreed engagement

Environment / release / date

Accountable owner

Expected result / acceptance threshold
Complete for the agreed engagement
Observed result / evidence reference
Complete for the agreed engagement
Exception / decision / follow-up owner
Complete for the agreed engagement

Sample deliverable

VMware platform baseline and change checklist

A platform baseline connecting release compatibility, workload acceptance, and operational handover.

Download .md template
Scope
Installed releases, hardware, storage, networks, and workload owners.
Checks and review
  • Check release and hardware compatibility.
  • Validate workload checks, recovery evidence, and handover.
Acceptance
Compatibility, acceptance, and operational ownership documented.
View full worksheet: VMware platform baseline and change checklist

Use these fields to record the environment, acceptance criteria, evidence, and decisions for the agreed engagement.

Prerequisites

Inventory vCenter, ESXi, clusters, vSAN architecture, hardware and firmware, networks, backup systems and guest application owners. Record installed and target releases and vendor entitlement.

Checks and review

  1. Check release interoperability and hardware compatibility. Agree management, networking, storage and representative workload tests with expected results and named acceptance owners.
  2. Document stop conditions, authorized change and recovery procedures, and measured restore evidence. Record exceptions and operational handover before accepting the change.

Illustrative expected result: Release and compatibility findings recorded; platform and workload checks accepted; recovery evidence and operational ownership documented.

Complete for the agreed engagement

Environment / release / date

Accountable owner

Expected result / acceptance threshold
Complete for the agreed engagement
Observed result / evidence reference
Complete for the agreed engagement
Exception / decision / follow-up owner
Complete for the agreed engagement

Plan your next production change

Share the source and target releases, affected interfaces and available change window. We will review the dependencies with you and propose an assessment, implementation scope or support plan.