Migrating from PowerTerm to IMTerm

Why Migrate Now

PowerTerm entered end-of-life in March 2025. Ericom, the maker of PowerTerm, stopped releasing security patches. Support contracts are non-renewable after 2027. Organizations running PowerTerm are now running unsupported, unpatched software on every PC that needs AS/400, z/OS, or VT220 access.

The practical risks today: - Browser compatibility breaks as Chrome and Edge update (ActiveX is already gone) - Java dependency means PowerTerm stops working as organizations phase out Java - No fix for discovered security vulnerabilities - License renewal is unavailable for new seats

What does NOT need to change: - Your AS/400 applications, programs, and data - nothing on the host changes - Your users' usernames and workflows - they use the same menus and screens - Your printer devices and spool queues - IMTerm connects as a standard network printer

What Changes

Migration Checklist

Phase 1: Inventory (Day 1)

Find all PowerTerm installations:

REM Windows: scan domain for PowerTerm
wmic /node:@computers.txt product where "name like '%PowerTerm%'" get name,version,installdate

Or use your software inventory tool (SCCM, Lansweeper, etc.) to query for PowerTerm installations. You need a count of active users, not just installed copies.

Document connection settings: For each connection profile in use, record: - Host name or IP address - Port (usually 449 for TN5250, 23 for TN3270/VT) - Terminal type (IBM-3179, IBM-3477, etc.) - CCSID / code page (424 for Hebrew, 37 for US, 500 for International) - SSL/TLS enabled or not - Device name pattern (if any)

Gather this from a sample of 5-10 representative users' PowerTerm .ptc profile files, usually in %APPDATA%\Ericom\PowerTerm\Profiles\.

Find PSL scripts in use:

dir /s /b %APPDATA%\Ericom\PowerTerm\*.psl

List all .psl files across user profiles. Sort by last-modified date - scripts not touched in 2+ years are probably unused.

Phase 2: Install IMTerm Server (Day 2)

Install IMTerm on a Linux server (or Windows if required):

# Download and install
wget https://releases.infomanta.com/imterm/imterm-2.0.1-linux-amd64.tar.gz
tar xzf imterm-2.0.1-linux-amd64.tar.gz -C /usr/local/bin
chmod +x /usr/local/bin/imterm

# First-run setup
imterm --generate-config > /etc/imterm/config.yaml
# Edit config.yaml: set your host details, admin password

# Start as a service
imterm --generate-systemd > /etc/systemd/system/imterm.service
systemctl enable --now imterm

# Create the admin account
imterm user add --username admin --role admin

Verify by opening http://server-ip:8080 in a browser.

Phase 3: Create Connection Profiles (Day 3)

Replicate each PowerTerm connection profile in IMTerm:

In IMTerm admin console (Admin > Connections > Add): - Name: same as the PowerTerm profile name (helps users recognize it) - Host: same IP/hostname - Port: same port - Protocol: TN5250E for AS/400, TN3270E for z/OS, VT220 for Linux/SSH - CCSID: same code page (424 for Hebrew, etc.) - TLS: same as PowerTerm

For large deployments, create connection profiles via API instead of the UI:

# Import from CSV: name,host,port,protocol,ccsid
imterm profile import --csv connections.csv

PowerTerm .ptc file import (where available):

imterm profile import --ptc user_profile.ptc

Not all .ptc fields map directly. IMTerm logs what was imported and what requires manual review.

Phase 4: Convert PSL Scripts (Day 4)

Convert PSL scripts to IMTerm JavaScript:

# Convert all scripts
imterm psl2js --dir /path/to/psl-backup/ --out-dir /etc/imterm/scripts/

# Review conversion output
cat /etc/imterm/scripts/auto-signon.js

PSL constructs that convert automatically: - type, sendkey, wait screen, read, print → equivalent session API calls - Variables, conditionals, loops → JavaScript equivalents

PSL constructs that need manual review: - DDE (Windows Dynamic Data Exchange) calls - IMTerm has no equivalent; document them as manual steps or replace with REST API calls - PowerTerm-specific functions (pt_...) - review case by case - File I/O - use session.result() or the REST API instead

Test each converted script in IMTerm before removing PowerTerm from any PC.

Phase 5: Pilot Rollout (Days 5-10)

Select 5-10 users who are willing to test early. Choose a mix: - Heavy users (use AS/400 all day) - Light users (occasional access) - Hebrew users (if applicable) - Users who rely on PSL scripts

Send each pilot user: 1. The URL: https://imterm.corp.com (or whatever your server address is) 2. Their username (create IMTerm accounts or configure SSO) 3. A 1-page quick reference card (see IMTerm-QuickStart-* guides)

Collect feedback for one week. Common first-week feedback: - "Keyboard shortcuts are different" (see keyboard mapping section below) - "My F-key labels aren't showing" (enable keyboard bar in View menu) - "Print isn't working" (see print migration section)

Fix issues before broad rollout.

Phase 6: SSO Setup (Day 10)

Configure Single Sign-On so users are not prompted for a separate IMTerm password. Options:

LDAP (Active Directory):

auth:
  provider: ldap
  ldap:
    url: ldap://dc01.corp.com:389
    bind_dn: "CN=imterm-svc,OU=Service Accounts,DC=corp,DC=com"
    bind_password: "${LDAP_PASSWORD}"
    base_dn: "OU=Users,DC=corp,DC=com"

Users sign in with their Windows domain credentials.

Kerberos SPNEGO (zero login): Configure Kerberos as described in Article 7. Users on domain-joined PCs open IMTerm and are automatically authenticated - no login screen at all.

Phase 7: Full Rollout (Day 14+)

Send all users the URL and notify them that PowerTerm will be removed on a specific date.

Decommission PowerTerm:

REM Remove from all PCs via Group Policy or SCCM
wmic product where "name like '%PowerTerm%'" call uninstall /nointeractive

Feature Mapping: PowerTerm to IMTerm

Features PowerTerm never had (new in IMTerm): - Agent Mode (AI navigates AS/400 on your behalf) - Screen-to-HTML (automatic modern form overlay) - REST API (integrate AS/400 data with any application) - RBAC with audit trail - FIPS 140-2 cryptography - Browser-based (no install) - Kerberos SPNEGO - mTLS client certificates - Session recording with MP4 export - Print archive with 7-year retention

Hebrew Migration

PowerTerm's Hebrew support was a separate localized build (PowerTerm XL or PowerTerm Hebrew). Hebrew required purchasing the Hebrew version, separate registration, and careful CCSID configuration.

IMTerm has Hebrew built in to every build. No Hebrew-specific version. No additional license.

In PowerTerm: The Hebrew package installed separate DLLs and added Hebrew to the terminal engine via a Windows COM component.

In IMTerm: Hebrew support is in the Go core and the TypeScript frontend. CCSID 424 (Hebrew New) and 803 (Hebrew Old) are both supported natively. The BiDi rendering engine (bidi-js) handles mixed Hebrew/English automatically.

Migration steps for Hebrew users: 1. Set CCSID to 424 on the connection profile (matches the AS/400's CCSID) 2. Enable Screen Reverse if your AS/400 application uses reversed screen mode (common for older Hebrew apps) 3. Test on a Hebrew screen - characters should display correctly immediately 4. For print: set the printer session CCSID to 424 and verify PDF output

If characters appear garbled after migration, verify the CCSID setting on the connection profile. The most common cause is CCSID mismatch between IMTerm and the AS/400 job's CCSID.

Keyboard Mapping

PowerTerm keyboard mappings use proprietary shortcuts. IMTerm uses keyboard mappings configurable per-profile.

Default IMTerm keyboard shortcuts:

Customizing keyboard mappings:

In Session > Keyboard Settings, you can remap any key. Export the keymap as a JSON file and share it with users to ensure everyone has the same mapping.

PowerTerm keymap import:

If you have PowerTerm keymap files (.ptk), the converter tool can extract the mappings:

imterm psl2js --ptk powerterm.ptk --export-keymap keymap.json

Then import in IMTerm: Session > Keyboard Settings > Import.

Print Migration

PowerTerm printing: PowerTerm printer sessions used a proprietary SCS implementation and routed print jobs through the Windows print spooler. Output quality for Hebrew was inconsistent.

IMTerm printing: Pure-Go SCS parser producing PDF directly. No Windows print spooler. Consistent Hebrew output across all environments.

Migration steps:

1. Identify each PowerTerm printer session profile (usually visible in PowerTerm connection settings as "Printer Session")
2. For each printer session, note: host, port, device name, CCSID, paper size
3. Create a matching printer session in IMTerm (Admin > Printer Sessions > Add)
4. Vary on the AS/400 device: VRYCFG CFGOBJ(IMTRMPRN1) CFGTYPE(*DEV) STATUS(*ON)
5. Test: print a report from the AS/400, verify the PDF in IMTerm's print job list

Print archive: PowerTerm had no print archive. IMTerm automatically archives all print jobs when the archive is enabled. This is a new capability you get for free during migration.

Macro Migration

PowerTerm macros are recorded or written in PSL (PowerTerm Script Language). IMTerm converts them automatically:

imterm psl2js macro.psl -o macro.js

The converted JavaScript is functionally equivalent. Review it before deploying to production - especially any macro that inputs credentials (make sure passwords aren't hardcoded in the converted file).

PSL functions with direct equivalents:

FAQ

Q: Do I need to keep PowerTerm licenses during migration?

No. Once IMTerm is running and tested with your pilot group, you can decommission PowerTerm. IMTerm's license is independent of PowerTerm.

Q: Can users run both PowerTerm and IMTerm at the same time during migration?

Yes. They connect to the same AS/400. IMTerm and PowerTerm both use TN5250E - they don't conflict. Users can switch between them during the pilot period.

Q: What if a user has a PowerTerm keyboard macro they use constantly?

Convert it with imterm psl2js and load it into IMTerm. The user can assign a keyboard shortcut to it in Session > Keyboard Settings > Macros.

Q: Our AS/400 device names are registered in the network. Do we need to change them?

No. If PowerTerm was using device name PTUSERJSMITH, create an IMTerm connection profile that uses the same device name. The AS/400 does not know it's a different emulator.

Q: Does IMTerm support PowerTerm's PTX (PowerTerm WebConnect) architecture?

IMTerm is its own architecture (Go + React, browser-native). If you're running PowerTerm WebConnect, the migration path is the same: install IMTerm server, redirect users from the PTX URL to the IMTerm URL.

Q: How long does migration take?

Most organizations complete migration in 1-2 weeks: - Day 1-2: Inventory and install - Day 3-4: Connection profiles and PSL conversion - Days 5-10: Pilot with 10 users - Day 10-11: SSO setup - Day 14+: Full rollout

Hebrew-heavy organizations add 2-3 days for Hebrew validation and print testing.

Q: Will IMTerm work on tablets and mobile browsers?

Yes. IMTerm works in Safari on iPad and Chrome on Android. The terminal is touch-optimized with a virtual keyboard button. Performance is good for occasional use. Heavy users (full-time data entry) still prefer a physical keyboard.

Getting Help

• Evaluation request and migration assistance: sales@infomanta.com
• Technical questions during migration: support@infomanta.com
• PSL script conversion questions: include the .psl file in your support ticket
• Urgent issues: use the support portal at infomanta.com/imterm/support.html

Infomanta offers a paid migration service that includes: - Inventory of PowerTerm installations - Connection profile migration - PSL script conversion and testing - Pilot rollout support - Training session for IT team and end users

Contact sales for a migration quote.

See also: IMTerm-MigrationGuide.pdf (full migration guide with screenshots), 07-sso-kerberos-setup.md, 06-printing-cups-lpr.md