Internal + Customer SOP

Remote Support & Issue Resolution

How Endrias Bridge engineers diagnose and fix customer issues remotely — what the customer does, what the engineer does, and when to escalate. Includes the one-click Support Bundle feature built into the tool.

⚡ Auto Telemetry (Sentry) Escalation Channels Support Bundle (customer side) Engineer Diagnosis Workflow Common Issues & Fixes Tier SLAs Live Remote Session
⓪

Automatic Error Telemetry — Engineers See Issues Before the Customer Calls

Endrias Bridge sends every ERROR and FATAL log line to a private Sentry dashboard the moment it happens — automatically, with zero action required from the customer. This is exactly how Striim, Qlik, and CloudBasis handle remote diagnosis.

💻
Migration fails on customer's machine
ERROR appears in log
→
📡
App silently POSTs to Sentry
error + stack trace + OS + license tier
→
📊
Engineer sees it on Sentry dashboard
sentry.io/organizations/endriasbridge
→
Engineer emails customer with fix
before they even send a support ticket
✅
What IS sent (anonymous only)
  • Error message and Python stack trace
  • OS version and Python version
  • Hardware ID (opaque 16-char hash — not reversible)
  • License tier (Starter / Professional / Enterprise)
  • App version
🚫
What is NEVER sent
  • Connection strings, hostnames, or port numbers
  • Database credentials or passwords
  • Any row data from source or target database
  • Customer name, email, or company
  • Local variable values from stack frames
🔧
Engineer setup — one-time (5 minutes):
  1. Go to sentry.io → sign up with your endriasbridge.com email → create a new Python project named endrias-bridge
  2. Copy the DSN from Settings → Projects → endrias-bridge → Client Keys
  3. Open migrationbridge/gui/telemetry.py and replace _DSN = "https://REPLACE_WITH_YOUR_DSN@..." with the real DSN
  4. Rebuild and ship — every subsequent customer error appears on your dashboard instantly
ℹ
Customer opt-out: Customers can disable telemetry by adding telemetry_enabled = false to their migrationbridge.conf file. This is disclosed in the privacy section of the EULA.
✅
What this looks like in practice: Customer runs a migration Friday evening. It fails with an FK violation on dbo.OrderLine. Sentry sends you an email alert at 8:47 PM. By the time the customer opens their laptop Monday morning to write a support ticket, you have already replied with the exact fix. That is the Striim/Qlik experience.
①

When Telemetry Isn't Enough — Four Escalation Channels

Sentry catches unhandled errors automatically. For issues that need deeper investigation — configuration problems, firewall issues, environment mismatches — there are four escalation channels.

📦
Log Bundle + Email
Customer clicks Export Support Bundle in the Error Log tab. One .zip file captures all logs + system info. They email it to info@endriasbridge.com. Use when Sentry has the error but needs more context (configuration, environment).
🖥
Screen Share (guided fix)
For issues that need real-time observation — Zoom or Microsoft Teams screen share. Customer shares their screen, engineer walks them through the fix live. Typical session: 15–30 minutes. Available for Professional and Enterprise tiers.
🔑
Remote Desktop (hands-on)
For complex issues: customer grants temporary remote desktop access via Windows Quick Assist, TeamViewer, or AnyDesk. Engineer takes over the machine, reproduces the error, and fixes it directly. Restricted to Enterprise tier with SLA commitment.
🚀
Patch Delivery (code fix)
If the issue is a software bug confirmed via Sentry: engineer fixes the code, builds a new installer, and delivers it via a GitHub release link. Turnaround: 1–5 business days depending on complexity and tier SLA.
ℹ
The most powerful thing: Because Sentry captures the error automatically, engineers often know the root cause before the customer asks. The Support Bundle and screen share channels exist for the cases where the error alone isn't enough — environment config, firewall rules, or credential issues that don't appear in the stack trace.
②

Customer Guide — Export Support Bundle (1 click)

When something goes wrong, the first thing support needs is the log bundle. Here is exactly where to find the button and what to do with it.

1
Open the DB Migration window and go to the Error Log tab
The Error Log tab is near the top of the DB Migration window, between the Run tab and other tabs. It shows a badge with the error count after a run, e.g. 3 issues.
DB Migration Window — Tab bar showing Error Log tab
DB Migration
Run
Error Log (3 issues) ← click here
Jobs
Error Log tab content shown here
2
Click the 📦 Export Support Bundle button
The button is in the toolbar at the top of the Error Log tab, to the left of the "Open log folder" button. It is purple and labeled 📦 Export Support Bundle.
Error Log Tab — Toolbar
Clear
Saving: migration_run_20260626_143201.log
📦 Export Support Bundle ← click here
Open log folder
3
Choose a save location and click Save
A Save dialog opens with a default filename like EndriasBridge_SupportBundle_20260626_143201.zip. Save it to your Desktop or Downloads folder.
4
Email the .zip file to info@endriasbridge.com
A success dialog will appear confirming the bundle is ready and showing the support email. Attach the .zip file to an email with a brief description of what went wrong (e.g. "Migration failed at dbo.OrderLine — FK violation error").
✅
What's inside the bundle:
  • All .log files from the migration_logs/ folder (every recent run)
  • Current Error Log tab contents
  • OS version, Python version, machine info
  • Hardware ID and license status
No connection passwords, no source data, no database contents are included.
③

Engineer Workflow — Diagnosing from a Support Bundle

When a support bundle email arrives at info@endriasbridge.com, follow this workflow to diagnose and resolve the issue. Most tickets are resolved in steps 1–3 without needing a live session.

1
Unzip and read sysinfo.txt first
This gives you OS, Python version, hardware ID, and license tier in seconds. Confirm the license is valid and not expired — an expired license causes silent failures on some operations.
# sysinfo.txt — check these fields first: OS : Windows 11 Pro 10.0.26200 Python : 3.11.4 Hardware ID : a1b2c3d4e5f6g7h8 License : Active — 14 days remaining (expires 2026-07-10)
2
Open the most recent migration_logs/migration_run_*.log
Log files are named migration_run_YYYYMMDD_HHMMSS.log. Open the one with the timestamp closest to when the customer reported the problem. Scan for these markers in order:
# Search for these keywords (Ctrl+F in any text editor): ERROR — hard error, usually has a stack trace below it WARNING — non-fatal but important FATAL — migration aborted FK violation — foreign key constraint failure timeout — connection or query timeout permission — permission denied on source or target SqlException — SQL Server driver error (has error code) OperationalError — SQLAlchemy connection error # Progress markers that confirm how far it got: Copying dbo.TableName — currently copying this table ✓ dbo.TableName — completed successfully ✗ dbo.TableName — failed on this table === Migration DONE — completed normally === Migration FAILED — aborted with error
3
Match the error to the Common Issues table (Section 4 below)
The majority of issues fall into 6 categories. Look up the error keyword and follow the fix steps. Reply to the customer with the exact fix — usually a settings change or a specific option to enable in the wizard.
4
If log is insufficient — request a screen share session
Reply to the customer and ask them to schedule a 30-minute Zoom/Teams session. During the session: ask them to reproduce the error while you watch. You can guide them through settings changes in real time.
ℹ
Zoom screen share checklist (before session): Ask the customer to have ready: the source DB credentials, the target DB credentials, and the last migration report HTML file. Have them open the Error Log tab before starting the share so you can see the issue immediately.
5
If it's a code bug — reproduce locally and issue a patch
Use the customer's sysinfo.txt to match their environment. Reproduce using AdventureWorks or a similar public test database. Fix the code, rebuild the installer (PyInstaller + Inno Setup), and deliver the patch via a private GitHub release or direct file transfer.
🐛
Reproduce bug locally
match customer's OS + DB version
→
🔧
Fix & rebuild
PyInstaller → new .exe
→
Deliver patch
GitHub private release or direct download link
→
✅
Customer confirms fix
closes ticket
④

Common Issues & Remote Fixes

These are the issues that appear most frequently in support logs. Each has a log keyword to search for and an exact fix the engineer can give the customer in a single email reply.

Log keyword Cause Fix (tell the customer) Needs live session?
FK violation Tables migrated in wrong FK dependency order — child before parent In the DB Migration tab, uncheck "Preserve insert order" and re-run. The FK sort algorithm will re-order. No
Login failed Wrong username / password or SQL Auth not enabled on target Verify target DB has SQL Server Auth enabled (not Windows-only). Re-enter credentials in Step 5 and test connection. No
timeout expired Query taking longer than 30s default — large table or slow network In Settings → Advanced, increase "Query timeout" to 300 seconds. For very large tables use BACPAC Seed instead. No
SqlPackage not found SqlPackage.exe not installed — needed for BACPAC Seed Run in terminal: dotnet tool install --global microsoft.sqlpackage then restart Endrias Bridge. No
permission denied Source DB user missing db_datareader or target user missing db_owner Grant: EXEC sp_addrolemember 'db_datareader', 'user' on source. EXEC sp_addrolemember 'db_owner', 'user' on target. No
NullType / UDT column User-defined type column can't be reflected by SQLAlchemy The tool already casts UDT columns to TEXT automatically. If migration still fails, provide the CREATE TYPE DDL for the affected column to support for a targeted fix. Maybe
License expired Trial or subscription expired Generate and email a new license key. Collect HWID from sysinfo.txt in the bundle, run trial_keygen.py --hardware-id <hwid> --days 365. No
Connection refused Firewall blocking port 1433 between migration machine and target Customer must open inbound TCP 1433 on target security group / Windows Firewall for the migration machine's IP. Provide exact AWS SG or Windows Firewall rule. Screen share
No module named Python dependency missing — usually after manual Python install Ask customer to reinstall using the official installer (MigrationBridge_Setup.exe) which bundles all dependencies. Do not use pip install. No
row count mismatch Rows written to source during migration window — CDC not enabled Run Resume migration — it detects partial tables and re-syncs. Or enable CDC mode before the next run to capture changes during copy. No
⑤

Support Tier SLAs

Response and resolution times vary by license tier. These are the commitments made to customers — internal target is to resolve within half the SLA window.

Tier Channel First response Resolution target Live session Remote desktop
Starter Email only (GitHub Issues accepted too) 72 hours Best effort — —
Professional Email priority queue 24 hours 3 business days ✓ Zoom/Teams —
Enterprise Email + dedicated Slack channel 4 hours (business hours) 1 business day ✓ Zoom/Teams ✓ TeamViewer/RDP
⚠
Out-of-scope items (all tiers): Network configuration on the customer's infrastructure, firewall rule implementation, AWS security group changes, or any work on the customer's source/target database servers are out of scope for software support. We guide, the customer implements.
⑥

Live Remote Session Runbook (Engineer Side)

When a screen share or remote desktop session is needed, follow this runbook. Total expected time: 15–45 minutes depending on issue complexity.

1
Before the session — review the support bundle
Read all log files and sysinfo.txt before the call. Write down the exact error line and the last successful table name. Have the Common Issues table (Section 4) open. Know what you're going to look for before sharing starts — the customer's time is the SLA clock.
2
Screen share — open Zoom or Teams, ask customer to share screen
Ask the customer to open Endrias Bridge and navigate to the exact screen where the problem occurs before sharing. Once shared:
  • Confirm the Error Log tab content matches what's in the bundle
  • Check Step 5 connection settings (without reading passwords — just verify host/port)
  • Ask them to run a Test Connection so you can see the result live
  • Guide them through any settings changes step by step
  • Ask them to re-run the failing migration so you can watch the log in real time
3
Remote Desktop (Enterprise only) — Windows Quick Assist
The safest zero-install option. Customer presses Win and searches "Quick Assist". They click "Get Help" and share the 6-digit code with you. You enter the code on your machine and take control.
# Customer does this: Win key → search "Quick Assist" → Get Help → share 6-digit code with engineer # Engineer does this: Win key → search "Quick Assist" → Give Help → enter 6-digit code → Take full control
🔒
Security ground rules for any remote session: Never ask the customer to type passwords while you are in control. Never access any database or file outside the EndriasBridge application directory. Disconnect immediately when the issue is resolved. Confirm with the customer that the session has ended.
4
Close the session — document what was done
After the session, email the customer a summary of: what the root cause was, what was changed, and how to prevent it. Log the issue internally (spreadsheet or GitHub Issues label "support-resolved") so the same error can be diagnosed faster for the next customer.
✅
If the issue was a software bug (not user configuration), open a GitHub issue tagged bug / customer-reported with the log line, root cause, and a test case. This becomes the backlog for the next patch release.