ClonePartner Envoy: the on-prem migration agent

Before we dive into what ClonePartner Envoy is, it helps to be aware of how ClonePartner and most cloud-hosted solutions run migrations today -

How ClonePartner runs migrations today

Most of our customers start with the standard hosted model because it is faster to get going and more cost effective.

Today's standard pipeline looks like this:

1. Data is pulled from the source system using official APIs or exports.
2. It is stored in a migration database hosted in the EU.
3. Truto, our data transformation layer, performs all the mapping, cleaning, and reshaping.
4. Data is then pushed into the destination system.
5. Migrations are monitored and validated by our engineering team.

This model is already built for security conscious teams:

• ClonePartner is audited against SOC 2 Type II, which focuses on controls around security, availability, processing integrity, confidentiality, and privacy.
• Our information security program is aligned with ISO 27001, the leading standard for information security management systems.
• Our processes are built to respect GDPR, HIPAA, and similar privacy and security regimes that require strong administrative, technical, and physical safeguards for personal and health data.

For many mid-market and a good number of enterprise customers, this is sufficient and simpler operationally.

But some security teams have a hard requirement:

"The data cannot leave our VPC or data center. Not even temporarily. Not even to an EU-hosted migration database."

That is exactly the problem Envoy solves.

Introducing ClonePartner Envoy: an on-prem migration agent

ClonePartner Envoy is a deployment option for customers with strict data residency, regulatory, or internal risk requirements.

The core principle is simple: your data never leaves your environment. No data is sent to, stored on, or processed inside ClonePartner infrastructure at any point during the migration.

At a high level:

• You receive an executable file (or container image) from ClonePartner.
• You run it inside your own environment (VPC, on-prem, private cloud).
• It connects only to:
• • the source system, and
  • the destination system.
• Logs are generated locally and never leave your infra unless you decide to share them.
• No one at ClonePartner, including the migration engineer who authored the executable, can see your data.

From a CISO's perspective, Envoy behaves like an on-prem agent that executes a predefined migration playbook, with all the logic baked into it, but with zero persistent vendor data access.

How Envoy works under the hood: migrations as if your own team built them

Think of Envoy as a compiled version of a typical ClonePartner migration pipeline.

1. We design the mapping with you

• Which objects are in scope (tickets, deals, contacts, users, attachments, custom entities).
• How fields map (one-to-one, many-to-one, or via transformations).
• How to handle edge cases, historical data, and custom workflows.

2. We encode the mapping and flows into a self-contained executable

• Schema mapping
• Transformation rules (what Truto usually does)
• Rate limiting and retry behavior
• Validation rules
• Logging and observability hooks

3. You deploy and run Envoy inside your environment

• On your own VM, container cluster, or bare metal.
• Using your own network policies, secrets management, and IAM.

4. Envoy talks directly to your systems

• Outbound calls only to the source and destination APIs or data stores.
• No calls to ClonePartner servers.
• Optional calls to your internal logging or monitoring stack (SIEM, APM) if you choose.

5. Debugging happens via redacted logs

• Envoy writes local log files that contain no raw data, only:
• • error codes,
  • field names,
  • identifiers that you are comfortable exposing (or hashed references),
  • stack traces and technical details.
• Your team reviews and optionally masks anything they consider sensitive before sharing logs with us.
• We reproduce the issue using synthetic data and ship you a new executable if needed.

The net effect: ClonePartner sees behavior, not data.

Why legal, security and compliance teams care

Regulations place specific obligations on cross-border data transfers and third-party processing:

• GDPR Articles 44–49 govern international transfers of personal data outside the EEA. They require adequacy decisions, standard contractual clauses (SCCs), or other approved safeguards before personal data can leave its region.
• HIPAA's Security Rule (45 CFR § 164.312) requires covered entities and business associates to implement technical safeguards — including access controls, audit controls, integrity controls, and transmission security — for electronic protected health information (ePHI).
• India's DPDP Act (Section 16) restricts transfer of personal data to jurisdictions not approved by the Central Government, placing obligations on data fiduciaries to ensure adequate protection.

Envoy sidesteps the most complex parts of these frameworks for the migration itself:

• Data stays within your environment, so no additional cross-border transfer mechanism is needed.
• Your existing controls (ISMS, BAA framework, access management) continue to apply because Envoy runs inside your system boundary.
• You are not adding a new external processor for the migration data itself.
• Audit trails, access controls, and monitoring all stay under your existing tooling.

In practice, Envoy becomes a strong answer to questions like:

• "Where exactly does this data go during the migration?"
• "Who can access it at any point in time?"
• "Do we need a new cross-border transfer assessment just for this project?"
• "How do we prove that this vendor does not retain a copy of our data?"

So instead of writing a new chapter in your DPIA for "third-party migration database in another region", Envoy often fits into your existing "internal processing" model with a smaller delta.

What's included in the deliverables?

Envoy is not a black box. It is a program with three key concepts:

1. A configuration file
2. A secret store integration
3. A JavaScript runtime based migration engine

1. Configuration file: what to move and how to monitor it

The executable you receive accepts a configuration file that your team can read and version control.

In that config you define:

• Resources to sync
• • Which objects: tickets, users, contacts, deals, notes, attachments, custom entities
  • Which subsets: date ranges, status filters, archived vs active, etc.
• Speed and batching
• • How quickly to sync resources
  • Batch sizes and pagination settings
  • Retry intervals and limits
• Health checks
• • HTTP health check endpoints that your monitoring stack can ping to ensure the process is alive
  • Status endpoints you can hook into Prometheus, Datadog, New Relic or similar
• Notifications
• • Optional integrations so you can, for example, receive alerts on Slack or Microsoft Teams when:
  • • a run starts or finishes
    • error rates cross a threshold
    • specific resource types fail too often

The config is what binds Envoy to your operational reality: how aggressive you want to be, how you monitor, and how you get notified.

2. Secrets: encrypted at the OS level, not in files

Credentials are often the scariest part for security teams.

Envoy ships with a CLI that includes a secret subcommand. Your team uses that to inject secrets such as:

• OAuth client IDs and secrets
• API tokens
• Service account credentials

Key points:

• Secrets are not stored in config files
• Secrets are not stored in .env files
• Secrets are stored encrypted at the OS level using the platform's secure credential store
• Only the Envoy program has access to them at runtime

So your runbook looks like:

1. Provision a host or container
2. Install Envoy
3. Use the CLI to set credentials into the OS level store
4. Keep the config file free of raw secrets

When you run Envoy, it:

• Pulls secrets from the OS key store
• Fetches access tokens (for example OAuth) as needed
• Reads the configuration file
• Starts the migration immediately on that machine

3. Runtime model: single threaded code, multi threaded IO

Envoy uses a JavaScript runtime under the hood.

That gives you:

• A single threaded event loop for the migration logic
• Highly concurrent, multi threaded I/O for all network calls and disk operations

In practical terms:

• The code that decides "what to do next" is single threaded and deterministic
• All the heavy lifting - API calls, reading/writing temporary files, etc - is handled by a multi threaded I/O layer

Result: you get high throughput on API calls and disk operations without the complexity of managing your own worker pool.

Where the data lives during an Envoy migration

Everything is local to the machine where Envoy runs:

• API calls from the source terminate on that host
• Temporary data is buffered and processed on that host
• API calls to the destination originate from that host

There is no hop through a ClonePartner controlled environment. The ingress and egress points are inside your own perimeter.

Envoy vs standard ClonePartner migrations: how to choose

Dimension	Standard hosted	Envoy (on-prem)
Setup time	Faster — we manage infra and can iterate in real time	Longer — requires mapping workshops, test builds, and your team provisioning the runtime environment
Cost	Lower — shared infrastructure, less manual mapping	Higher — dedicated executable per customer, more engineering hours upfront
Data residency	Data transits through ClonePartner's EU-hosted migration database	Data never leaves your VPC or data center
Security posture	SOC 2 Type II audited, ISO 27001 aligned, GDPR and HIPAA processes	All of the above, plus data stays inside your own ISMS boundary with zero external processing
Team involvement	Minimal — ClonePartner handles most operations	Significant — your platform/security teams provision, run, and monitor
Regulatory burden	May require vendor assessment, DPIA update, cross-border transfer analysis	Fits into existing "internal processing" model; smaller compliance delta
Iteration speed	Fast — config changes can be applied on the fly	Slower — every mapping change requires a new build and redeploy
Monitoring	ClonePartner monitors and alerts	Your team monitors; ClonePartner supports via redacted logs

Choose standard ClonePartner migrations when:

• You want the fastest time to value.
• Your security team is comfortable with a controlled, audited third-party processor that is SOC 2 Type II, ISO 27001, GDPR and HIPAA aligned.
• You are happy to leverage our hosted transformation and monitoring infrastructure.

Choose ClonePartner Envoy when:

• Your policy or regulator explicitly requires that data does not leave your VPC or physical environment.
• You cannot wait on extensive vendor assessments and reviews to bring ClonePartner onboard.
• Your CISO or DPO wants to minimize third-party data exposure as a matter of principle.
• You handle extremely sensitive datasets where any new external processor would trigger disproportionate review effort.
• You are comfortable investing more time and budget upfront to keep all processing in-house.

Many customers start on the standard model, prove out the migration approach, then move to Envoy for specific workloads or later phases that warrant the extra security posture.

Key considerations before choosing Envoy

Envoy is powerful, but it is not always the first or easiest choice. There are tradeoffs that matter, especially to engineering and operations teams.

Below is an expanded list of considerations to evaluate with your stakeholders.

1. Manual mapping effort (on ClonePartner's end)

Because Envoy is a compiled, self contained executable, all mappings are written explicitly before the agent ever runs in your environment.

• Every object type, field, and custom object must be defined upfront.
• Transformations that would be configured in a UI in the hosted model are now expressed as code or configuration embedded into the binary.
• Late stage changes (for example "we added 5 new custom fields last week") require a new build and redeploy.

Impact:

• More time in discovery, design, and mapping workshops.
• More iteration in non production or sandbox environments before production cutover.
• Higher upfront cost that pays off in very high comfort levels for security and compliance.

2. Customer responsibilities and internal ownership

With Envoy, you own the runtime.

Your teams will typically be responsible for:

• Provisioning the compute resources (VM, container, or on-prem host).
• Providing and rotating API keys, service accounts, or database credentials under your own secrets management.
• Managing network controls (allow lists, VPC endpoints, proxy settings).
• Triggering and monitoring runs (for example via cron, CI, or manual execution).
• Capturing logs and shipping them to your SIEM or log analytics stack.

This gives you greater control, but it also means:

• Security engineering or platform teams are usually involved from the start.
• There is a clear RACI around who "pushes the button" and who monitors the migration run.
• There might be internal change management overhead if a CAB or similar body must approve new binaries or scheduled jobs.

3. Observability, logs, and PII handling

Because ClonePartner cannot see production data, logs are the main collaboration surface.

Good practice includes:

• Configuring log levels (info, warn, error) in a way that balances debug depth with sensitivity.
• Logging field names, object IDs, internal error codes, and sample counts, but not full values.
• Using hashing or tokenization for any identifiers that must be shared externally for troubleshooting.
• Forwarding all logs to your SIEM so your SOC can monitor patterns during the migration window.

Your team can then selectively redact or mask log excerpts before sharing them with us for support.

4. Performance, scalability, and resource planning

In the hosted model, ClonePartner manages performance tuning, parallelism, and infrastructure scaling.

With Envoy:

• You decide how much CPU, memory, and network bandwidth to allocate.
• You can run multi threaded, multi worker, or batched migrations based on your own constraints.
• You can throttle migrations during business hours or run at full speed in predefined windows.

It is important to plan for:

• Non production test runs on representative data volumes.
• Understanding how long full runs and delta runs will take with your chosen resource profile.
• Any impact on source and destination rate limits or throttling.

5. Security architecture and threat model

From a threat modeling point of view, Envoy reduces the number of external processors of your data and keeps sensitive data within your existing network, encryption, and IAM controls.

Security teams should still review:

• Where the binary will run (isolated subnet, dedicated host, hardened base image).
• How access to that host is managed and audited.
• How binaries are verified before deployment. We provide checksums for integrity verification — talk to your ClonePartner engineer about the specific verification process for your deployment.
• How secrets are injected (for example via environment variables, vault integrations, or secret managers).

6. Regulatory posture and auditability

For regulated industries, auditors will likely ask:

• "Who is processing the data?"
• "Where is it processed?"
• "What controls apply?"

Envoy simplifies many answers:

• Processing stays within your own ISMS, which already maps to ISO 27001 and other frameworks.
• You can document Envoy as a controlled internal tool with clear access controls, logs, and change management.
• You avoid the need for additional cross-border transfer tooling just for the migration — relevant under GDPR Articles 44–49 and DPDP Act Section 16.

If you process health data, Envoy fits naturally into the HIPAA Security Rule's expectation (45 CFR § 164.312) that covered entities maintain technical safeguards for electronic protected health information inside their own environments.

7. Change management and iteration speed

Because every change to the mapping or behavior requires a new executable:

• It is wise to treat the mapping specification as a controlled artifact, with versioning and approvals.
• A dedicated UAT phase with realistic data and scenarios is essential.
• Feature requests like "can you also dedupe these two fields" are still feasible, but they go through a defined release cycle rather than an on the fly config change.

This is one reason Envoy projects take longer and cost more than our standard hosted migrations. You are trading flexibility and speed for an extremely tight security and data residency posture.

What a typical Envoy project looks like

1. Scoping and risk alignment

• Security, data protection, and engineering stakeholders align on scope, constraints, and goals.
• We confirm whether the standard hosted model is sufficient or if Envoy is the right default.

2. Mapping workshops

• Deep dive into your current and target schemas.
• Document all field mappings, transformations, filters, and edge cases.
• Agree on acceptance criteria and reconciliation rules.

3. Prototype and test binary

• We build an initial Envoy executable against your sandbox or non production environment.
• Your team runs it inside a test VPC or lab network.
• Together we validate logs, error handling, and performance.

4. Hardening and rollout

• Your security team reviews and approves the deployment pattern.
• We perform dry runs on production like slices of data where feasible.
• Change tickets, runbooks, and rollback procedures are documented.

5. Production cutover and validation

• Migration runs in controlled windows, with joint monitoring.
• Reconciliation and sign off are done against agreed thresholds.
• Envoy binaries are retired or archived according to your policies when the project is complete.