Migrating from Microsoft TMG 2011 is not just a technical upgrade—it’s a risk reduction and modernization exercise. Because TMG is end-of-life, every organization still running it should have a clear, controlled migration plan.
This checklist is designed to help you transition safely, avoid downtime, and maintain compliance.
Phase 1: Discovery & Assessment (Know What You Have)
✅ Inventory the Current TMG Environment
- Identify all TMG servers (physical/virtual)
- Document OS versions and patch levels
- Record TMG roles:
- Web proxy
- Firewall
- NAT
- Publishing rules
✅ Analyze Traffic & Usage
- Identify:
- Number of users
- Peak internet bandwidth
- Applications using proxy (browsers, apps, scripts)
- Export and review:
- Access logs
- Blocked traffic reports
✅ Document Policies & Rules
- User/group-based access rules
- URL filtering policies
- Protocol rules (HTTP, HTTPS, FTP, etc.)
- Authentication methods (AD, LDAP)
📌 Tip: Many organizations discover “hidden dependencies” at this stage (legacy apps hardcoded to TMG).
Phase 2: Risk & Compliance Review
✅ Identify Security Gaps
- Unsupported TLS versions
- Weak cipher usage
- Lack of modern malware inspection
- No zero-trust enforcement
✅ Compliance Considerations
- Logging retention requirements
- Audit trails
- Regulatory frameworks (NIST, ISO, PCI, local Qatar regulations)
📌 Decision Point:
Should migration be like-for-like or a security uplift?
Phase 3: Select the Right Modern Replacement
🔹 Common Modern Alternatives
Choose based on your environment:
On-Prem / Hybrid
- Next-Generation Firewalls (Palo Alto, FortiGate, Check Point)
- Secure Web Gateways (SWG)
Cloud-Based
- Zscaler
- Microsoft Defender for Internet Access
- Prisma Access
- Cisco Umbrella
Zero Trust
- ZTNA solutions
- Identity-based access enforcement
✅ Selection Criteria Checklist
- Active Directory / Entra ID integration
- SSL inspection capability
- Granular user-based policies
- High availability support
- Local support availability in Doha/Qatar
Phase 4: Design the Target Architecture
✅ Network Design
- Proxy mode vs transparent mode
- Inline vs cloud-based routing
- Internet breakout points
- Redundancy and failover
✅ Security Design
- Authentication flow
- Web filtering categories
- Malware inspection policies
- Logging and SIEM integration
📌 Best Practice: Design with Zero Trust principles, not perimeter-based assumptions.
Phase 5: Pilot & Proof of Concept (POC)
✅ Build a Test Environment
- Deploy new solution in parallel with TMG
- Select a pilot user group (IT or non-critical department)
✅ Validate Key Scenarios
- Internet browsing
- Business-critical web apps
- VPN or remote access
- Authentication & logging
✅ Performance Testing
- Latency
- SSL inspection impact
- Bandwidth handling
Phase 6: Migration Execution
✅ Phased User Migration
- Migrate users in batches
- Validate after each phase
- Keep rollback options ready
✅ Policy Mapping
- Recreate TMG rules in the new solution
- Avoid “copy-paste”—optimize where possible
- Remove outdated or unused rules
✅ DNS & Proxy Configuration
- Update:
- GPOs
- PAC files
- Browser settings
- Application proxy configs
Phase 7: Monitoring & Optimization
✅ Post-Migration Validation
- Confirm no internet outages
- Validate application access
- Monitor security alerts
✅ Log & Visibility Checks
- Ensure logs are:
- Captured
- Stored
- Searchable
- Integrate with SIEM if required
✅ Performance Optimization
- Fine-tune SSL inspection
- Adjust filtering categories
- Optimize bandwidth policies
Phase 8: Decommission TMG Safely
✅ Controlled Shutdown
- Disable TMG rules
- Power down servers (do not delete immediately)
- Monitor for hidden dependencies
✅ Secure Data Handling
- Archive logs if required
- Securely wipe disks
- Update network diagrams and documentation
📌 Never rush decommissioning—this is where outages often happen.
Phase 9: Documentation & Training
✅ Update Documentation
- New architecture diagrams
- Policy definitions
- Operational procedures
✅ Train IT & SOC Teams
- New console usage
- Incident response changes
- Troubleshooting workflows
Phase 10: Executive & Audit Sign-Off
✅ Final Review
- Security improvements documented
- Risk reduction demonstrated
- Compliance requirements met
✅ Management Sign-Off
- Confirm TMG is fully retired
- Approve production readiness
Real-World Migration Example (Doha-Based Enterprise)
A regulated enterprise in Doha migrated from TMG 2011 to a cloud-based secure web gateway:
Before
- 2 TMG servers
- Manual rule management
- Limited visibility
After
- Identity-based access
- Real-time threat intelligence
- Centralized cloud policy enforcement
Result
- Reduced security risk
- Improved user experience
- Compliance-ready logging
Final Thoughts
TMG 2011 served organizations well—but it belongs to another era.
A successful migration:
✔ Protects business operations
✔ Improves security posture
✔ Enables future-ready architecture
Treat migration as an opportunity, not just a replacement.
1) Quick translation: what TMG “is” in modern terms
TMG roles you may be using
Forward proxy (users → internet)
Firewall/NAT (network segmentation + outbound control)
Reverse proxy / Web Publishing (internet → internal web apps)
URL filtering + malware inspection (legacy)
User-based policies via AD
Modern equivalents
Zscaler:
ZIA = forward proxy / secure web gateway (internet access control)
ZPA = “publishing replacement” (zero-trust access to internal apps)
FortiGate / Palo Alto (NGFW):
Firewall policies + UTM / threat prevention
Optional explicit proxy features (forward proxy)
Reverse proxy is typically via separate product/module (FortiWeb, or Palo Alto + a dedicated reverse proxy like NGINX/F5; PAN has some reverse-proxy-ish patterns but not a 1:1 TMG publishing replacement in most designs)
2) Rule mapping: TMG rule types → modern policy types
A) TMG “Access Rules” (Outbound allow/deny)
TMG concept: Source (users/subnets) + Destination (URL/FQDN/IP) + Protocol + Schedule + User/Group.
Map to:
Zscaler (ZIA):
URL & Cloud App Control policies, Firewall Control (L3/L4), Advanced Threat rules
User/group enforcement via IdP/AD integration and client connectors
FortiGate:
Firewall Policy (src intf/src addr → dst intf/dst addr + service)
Add Web Filter / Application Control / IPS / Antivirus profiles
Palo Alto:
Security Policy (src zone → dst zone + App-ID/service/user)
Add URL Filtering / Threat Prevention / WildFire profiles
Translation tip:
TMG often uses “protocol rules” + “access rules.” In NGFW, it usually becomes one security policy with App/Service + security profiles.
B) TMG “Web Proxy filtering” (categories, file types, MIME, etc.)
Map to:
ZIA: URL categories, cloud app controls, file type controls, sandboxing options
FortiGate: Web Filter categories + file filtering (varies by license/features)
Palo Alto: PAN-DB URL Filtering categories + file blocking profiles
C) TMG “HTTP/HTTPS inspection”
TMG concept: SSL bridging / HTTPS inspection + cert distribution.
Map to:
ZIA: SSL inspection policies (forward proxy model) + client connector/cert deployment
FortiGate: Deep Inspection profile + enterprise CA distribution
Palo Alto: SSL Forward Proxy + Decryption policies + enterprise CA distribution
Gotcha:
Your biggest “surprise failures” post-migration are usually certificate pinning apps, finance/banking sites, and legacy TLS. Plan decryption bypass lists early.
3) Identity & authentication mapping (AD users/groups)
TMG
AD-based authentication for web proxy
Rule conditions by user/group
Map to:
ZIA: User identity via Client Connector, PAC, GRE/IPsec + IdP integration (Entra ID/AD)
ZPA: App access based on identity + posture checks (if enabled)
FortiGate: FSSO (AD integration) / LDAP / SAML as needed
Palo Alto: User-ID (AD integration) / GlobalProtect + SAML/LDAP
Translation tip:
If TMG policy is “Finance users can access X,” implement identity-based policy first, then refine apps/categories.
4) Publishing / Reverse proxy mapping (TMG Web Publishing Rules)
This is where migrations often go wrong because TMG did a lot of reverse proxy work.
TMG Web Publishing Rule includes:
Listener (public IP/port, cert)
Pre-auth (forms/NTLM/Kerberos)
Path-based publishing (/owa, /ecp)
Link translation
SSO constraints
Map to:
ZPA (preferred modern approach):
Replace “publish to internet” with Zero Trust private access
Users connect to apps without exposing inbound ports
Good replacement when the “public access” was mostly for employees/partners
FortiGate:
For true internet-facing publishing, typically use FortiWeb (WAF/reverse proxy) or a dedicated reverse proxy/load balancer. FortiGate itself can do VIP/NAT and some proxy features, but a WAF is closer to TMG publishing security.
Palo Alto:
Often done with PA + a dedicated reverse proxy/WAF (F5/NGINX/cloud LB)
PA excels at protecting the edge (zones, IPS, App-ID), but for “TMG-style publishing,” most enterprises add a proper reverse proxy/WAF.
Decision point:
If your goal is employee access to internal apps → ZPA (or VPN/ZTNA) is usually the cleanest replacement.
If your goal is public web apps → use a WAF/reverse proxy (FortiWeb/F5/Cloudflare/Azure App Proxy variants) plus NGFW.
5) Network objects mapping (TMG Networks, Network Rules, NAT)
TMG
Networks (Internal/External/DMZ)
Network rules (NAT/Route)
System policy + access rules
Map to:
Zscaler:
ZIA is not a “NAT appliance” in the same way; it’s policy enforcement based on user/device/traffic steering
You’ll still need routing/NAT at your edge (ISP firewall/router), but Zscaler handles the web security layer
FortiGate / Palo Alto:
Zones/interfaces = TMG Networks
NAT policies (SNAT/DNAT) = TMG Network Rules
“System policy” becomes platform management rules + implicit policies + admin controls
Translation tip:
Export TMG networks and redraw them as zones. That becomes your new policy skeleton.
6) Logging & reporting mapping
TMG logs
Web proxy logs, firewall logs
Often exported to SIEM
Map to:
Zscaler: NSS feeds / SIEM integrations for ZIA/ZPA logs
FortiGate: FortiAnalyzer / Syslog / SIEM
Palo Alto: Panorama / Cortex Data Lake / Syslog / SIEM
Minimum parity target:
User, URL/app, action, reason, bytes, source device/IP, policy name, threat verdict.
7) High Availability mapping (TMG NLB / array concepts)
TMG
Array + NLB / CARP-ish behaviors
Multiple nodes for proxy availability
Map to:
Zscaler: Cloud service HA is built-in; your HA focus is on connectivity/steering (dual ISP, redundant tunnels, client connector resilience)
FortiGate: HA active-passive/active-active clusters
Palo Alto: HA pairs + redundancy at routing layers