Appearance
Runbook: iMacros Migration Scoping
Purpose
Three workstations used for Medicare / billing workflows depend on iMacros, a legacy browser-automation tool, to drive repetitive portal interactions. All three machines remain on the legacy AD domain (not the current domain). The iMacros vendor's activation server has gone offline, which means reinstalling or reactivating the software on a replacement machine is not straightforward.
This document scopes the problem so a decision can be made without further investigation delay. It is a scoping runbook, not an implementation runbook — the path forward depends on vendor response (Kevin is the point of contact) and Rory's architectural sign-off.
Context
What is iMacros?
iMacros is a browser automation / web scripting product (originally Progress / Ipswitch / NICE). It records and replays browser actions — form fills, click paths, data extraction — and exposes a scripting language for parameterized runs.
At Cirius Group it is used to drive Medicare payer portal workflows — logging in, pulling claims, downloading remittance files, and reconciling billing data. The scripts were built years ago and have been running without material change. They are business-critical to the billing cycle.
Current state — the 3 machines
| Machine | Role | Status |
|---|---|---|
| Machine A | Primary iMacros workstation | Active, still running billing workflows |
| Machine B | Secondary iMacros workstation | Active, used as backup / parallel runs |
| Machine C | Historical / archive iMacros workstation | Unclear — may be unused, still on old AD |
All three are joined to the legacy AD domain — not the current production AD. They have not been migrated because the licensing situation (below) makes migration risky.
The vendor activation problem
iMacros historically phoned home to an activation server to validate licenses. Reinstallation or reactivation — triggered by reimaging, domain migration, or hardware replacement — requires the activation server to respond.
The vendor's activation server is currently offline. It is not confirmed whether this is temporary, permanent, or product-end-of-life. Without activation:
- Existing installs continue to work on the machines they're currently on
- Reimaging, migrating, or restoring any of the three machines could brick the iMacros install
- A completely fresh install on a new machine will fail at activation
This is why the 3 machines remain untouched on the legacy AD domain — any move risks breaking the billing workflow with no confirmed remediation path.
Migration Options
Three viable paths. Each has different risk/cost/effort. Decision is Rory's after Kevin's vendor contact completes.
Option 1 — Join new AD and re-activate
Approach: Unjoin from legacy AD, join to current AD, retain the existing iMacros install (no reinstall, no reactivation triggered).
Pros:
- Minimal touch on the iMacros binary — activation not re-invoked
- Brings the machines into the current domain (MDE, Cortex, patching, PIM all apply)
- Removes the legacy AD dependency
Cons / risks:
- Unknown whether a domain change triggers re-activation (product specifics vary). Some iMacros versions tie license to hardware, not domain — safer. Others tie to the logged-in user's SID — domain change changes SID → re-activation required → fails.
- No safe way to test without risking one of the machines. Testing on a dedicated test machine would require a fresh install first, which already fails.
- Reversal is non-trivial if it breaks — the legacy domain trust may not re-establish cleanly.
Prerequisites:
- Confirm iMacros version + licensing model (per-user SID vs per-machine hardware)
- Full Veeam backup of each of the 3 machines before attempting
- Rory approval on change ticket
Effort: 2–4 hours per machine assuming no issues; full day if troubleshooting.
Option 2 — Request fresh license from vendor
Approach: Kevin contacts the vendor. Request (a) a fresh license that does not require the activation server, (b) an offline license file, or (c) clarity on whether the product is end-of-life.
Pros:
- If successful, unlocks all the other options — we can freely reimage, migrate, replace hardware.
- Confirms product support status so we know whether this is a stopgap or a permanent solution.
Cons / risks:
- Vendor may not respond, may no longer exist as the original entity, or may require paid upgrade to a newer product to get fresh licensing.
- Sales cycle may be slow — not a same-week fix.
- If vendor declines, we're back to Option 1 or Option 3.
Prerequisites:
- Kevin has the original purchase records — license keys, order numbers, support contract references
- Kevin (or Adriana) identifies the current vendor entity — iMacros has changed hands multiple times (Progress, Ipswitch, NICE). Start with whoever issued the last support invoice.
Effort: 1 hour for initial outreach. Total duration 1–6 weeks depending on vendor responsiveness.
Option 3 — Decommission if unused (or build replacement)
Approach: Evaluate whether iMacros is still actively used on all 3 machines, or whether some workflows have been replaced by newer portals / APIs. Decommission any machine that is no longer required. For workflows that ARE still needed, build a replacement using modern tooling (Playwright, Selenium, or RPA — UiPath / Power Automate Desktop).
Pros:
- Permanently removes the legacy AD dependency and the activation risk
- Modern replacements are maintainable, testable, observable
- Replacement can run on domain-joined modern workstations with full security stack
- Eliminates "3 unsupported machines" from the inventory
Cons / risks:
- Highest effort — requires rebuilding scripts, regression testing against live payer portals, cutover planning
- Payer portal behavior changes over time — the replacement may need more ongoing maintenance than iMacros did
- Cannot begin until we know which workflows are actually still in use (audit step)
Prerequisites:
- Audit with billing team: which workflows on which machine, last-used date per workflow
- Inventory iMacros scripts per machine (export and version-control them regardless — this should happen even if we keep iMacros)
- Build-cost estimate — Playwright/Python rewrite is typically 1–3 days per workflow depending on complexity
Effort: 2–4 weeks elapsed for a workflow rebuild + testing. Decommission-only for an unused machine: 1 day.
Risk Assessment
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Domain join breaks iMacros activation (Opt 1) | Medium | High — billing disrupted | Full backup before attempt; one machine at a time; have rollback tested |
| Vendor unreachable / product EOL (Opt 2) | Medium-high | Medium — forces Opt 1 or 3 | Set 2-week timeout on vendor response before committing to another path |
| Machine hardware failure before any migration | Low-medium | Critical — no way to restore iMacros install | Start backups immediately; Veeam replication nightly for these 3 machines |
| Legacy AD compromise | Medium | High — 3 machines on unmanaged domain | Isolate at network layer (VLAN + firewall rules); minimize accounts on legacy DC |
| Staff knowledge loss of iMacros scripts | Low | Medium | Export scripts from machines NOW, commit to private repo regardless of path |
| Payer portal changes break scripts mid-migration | Low | Medium | Don't start Option 3 rebuild during year-end / Jan peak billing |
Recommended Next Steps
In order. Do not skip steps.
- [Kevin] Contact the vendor. Use the most recent support/sales contact on file. Specific asks:
- Is the activation server offline temporarily or permanently?
- Is the product end-of-life?
- Can an offline or transferable license be issued?
- What is the path for reactivation after a domain migration?
- Target: definitive answer within 2 weeks.
- [Kobe] Export iMacros scripts from all 3 machines and commit to a private repo regardless of which option is chosen. This is insurance against hardware loss and prerequisite to Option 3. No functional change to the machines — just copy the
.iim/.jsfiles out. - [Kobe + billing team] Audit workflow usage per machine. Which scripts on which machine actually run in the monthly cycle? Last-used date per script. This informs which machines we actually need to migrate vs decommission.
- [Rory] Decision gate. Based on vendor response + usage audit, Rory picks the path:
- Vendor gives fresh license → Option 1 or Option 2 (either works; pick based on timeline)
- Vendor silent / declines → Option 1 or Option 3; pick per workflow
- Some machines unused → Option 3 (decommission) for those; Option 1 or 2 for the rest
- [Kobe] Isolate the 3 machines at the network layer in the meantime. While a decision is pending, reduce blast radius:
- Confirm NSG/firewall rules limit these 3 machines to only the payer portals they need
- No Twingate/GlobalProtect access to these machines except for named admin accounts
- Full Veeam backup running nightly on all 3 (confirm — may already be in place)
- [Kobe] File a SecOps story per execution step once the path is decided.
Open Questions
- [ ] What is the exact iMacros version + edition on each of the 3 machines?
- [ ] Which vendor entity today owns iMacros — Ipswitch, Progress, NICE, or someone else?
- [ ] Are the 3 machines already in the Veeam replication set?
- [ ] Are there compliance implications to running billing workflows on legacy-AD machines (HIPAA — are PHI workflows on unmanaged domains a finding)?
- [ ] Does the billing team have documentation of each iMacros workflow, or is it tribal knowledge?
Related Documents
runbooks/incident-response.md— if the legacy AD domain is compromisedcompliance/three-layer-access-architecture.md— how isolated workstations fitrunbooks/dr-test-checklist.md— backup validation for these machines