Google Cloud Migration Center: When Enterprise Migrations Go Sideways

The Reality of Enterprise-Scale Discovery

Standard Migration Center setup breaks in predictable ways at enterprise scale. You have 3 ways to deploy this. Use option 2 unless you hate yourself. Here's what actually works after you've been burned twice by the default approach in environments with 5,000+ assets, complex networks, and legacy systems that haven't been touched since 2019.

Discovery Client Architecture for Scale

The discovery client 6.3.7 has performance improvements, but Google designed this thing for toy environments with 1,000 servers in a single data center. Real enterprises with multiple vCenters and legacy infrastructure? Yeah, you're on your own. The August 6, 2025 release fixed ZFS partition issues and floppy disk drives showing up in Linux scans (seriously, who still has floppy drives in 2025?), but they still haven't fixed the core scaling problems.

Deploy Multiple Discovery Clients Strategically

Instead of trying to scan everything from one discovery client, deploy multiple instances with clear boundaries:

• One discovery client per major data center - Network latency and firewall rules make cross-data center scanning unreliable
• Separate discovery clients for different credential domains - VMware environments with different service accounts, AWS accounts with different IAM roles
• Dedicated discovery clients for performance-sensitive environments - Production databases and critical applications should be scanned during maintenance windows with separate agents

Each discovery client maintains its own database and scan schedule, but all upload to the same Migration Center project. This approach prevents the single-point-of-failure issues that plague large monolithic discovery deployments.

Optimize Scan Scheduling for Production Impact

The custom scheduling feature introduced in version 6.3.0 lets you define opt-out schedules per server. This is critical for production environments where even the lightweight guest collection scripts can impact performance during peak hours.

What actually works in production:

• Development/test servers: Scan during business hours (9 AM - 5 PM)
• Production applications: Scan only during maintenance windows (Sunday 2-6 AM)
• Database servers: Scan during low-transaction periods (avoid month-end, quarter-end)
• Legacy systems: Manual coordination with application owners before any scanning

The discovery client collects performance metrics over time, so inconsistent scanning schedules will result in incomplete utilization data and inaccurate rightsizing recommendations.

Network and Credential Management at Scale

Managing Credentials Without Losing Your Mind

Most large discoveries die here. Google's credential management works great if you have one AD domain and a simple setup. Got 12 different AD forests, legacy systems with local accounts, and a security team that changes passwords weekly? Good luck.

Segmentation approach:

• Domain credentials: One set per AD domain/forest
• Local admin accounts: Separate credentials for servers not joined to domain
• Service accounts: Dedicated accounts for VMware vCenter, database instances
• Cloud credentials: AWS IAM roles, Azure service principals

Store credentials in enterprise password managers, not in the discovery client interface. Use the credential reset functionality to rotate accounts monthly as part of security compliance.

Network Dependencies and Firewall Planning

The discovery client needs network access on multiple protocols, and enterprise firewalls rarely have the ports configured correctly from the start. Plan for these network requirements:

Outbound from discovery client:

• TCP 443: HTTPS to Google Cloud APIs (required for uploading data)
• TCP 443: HTTPS to vCenter APIs (for VMware discovery)
• TCP 22: SSH to Linux servers (for guest-level collection)
• TCP 135, 445: WMI to Windows servers (for guest-level collection)
• TCP 3389: RDP for Windows troubleshooting (optional but recommended)

Inbound to target servers:

• Network scanning requires ICMP ping responses
• SSH daemon must accept connections from discovery client IP
• Windows Firewall must allow WMI traffic from discovery client subnet

Most enterprise network teams will push back on opening these ports broadly. The compromise solution is to deploy discovery clients inside each network segment, minimizing firewall rule changes.

Data Collection Optimization

Performance Impact Mitigation

Even with the performance improvements in version 6.3.4, guest-level collection can impact target systems during collection. The discovery client sets Linux collection scripts to run with higher nice levels and optimizes Windows collection, but this still causes CPU spikes on resource-constrained systems.

What actually happens to your servers:

• CPU impact: 5-15% CPU spike for 30-60 seconds (or until your monitoring explodes)
• Memory usage: 50-100MB temporary increase (watch out on 2GB legacy boxes)
• Disk I/O: "Minimal" until it hits that ancient Windows 2008 server with a dying disk
• Network bandwidth: 1-5MB per server (multiply by 2,000 servers during peak hours)

I learned this the hard way when discovery scanning triggered a cascade failure on a production ERP system running at 95% CPU. That was a fun Saturday morning explaining to the CTO why payroll was down.

Storage and Database Performance

The discovery client stores collected data in a local SQLite database before uploading to Migration Center. For large environments, this database can grow to several gigabytes and become a performance bottleneck.

Database maintenance practices:

• Monitor database size: Check C:\ProgramData\Google\mcdc\data\ folder size weekly
• Storage requirements: Plan for 2-5MB per discovered server for historical data
• Backup strategy: Export collected data to Migration Center before major discovery client upgrades
• Database corruption: Use the recovery commands if database issues occur

The discovery client periodically cleans up old data, but environments with frequent re-scanning can accumulate significant data volumes.

Integration with Enterprise Tools

CMDB and Asset Management Integration

Migration Center doesn't integrate directly with enterprise Configuration Management Databases (CMDBs), but you can bridge this gap with the CSV import functionality. Export server data from ServiceNow, BMC Remedy, or other CMDB tools and import into Migration Center to supplement automated discovery.

Common integration scenarios:

• Asset ownership data: Application owners, business units, cost centers
• Compliance classifications: PCI, HIPAA, SOX scope servers
• Change management schedules: Maintenance windows, upgrade schedules
• Business criticality: Tier 1/2/3 application classifications

This manual data enrichment is essential for meaningful migration wave planning and risk assessment.

Monitoring and Alerting Integration

The discovery client generates logs that you can forward to Cloud Logging, but enterprise environments need integration with existing monitoring tools. Export discovery client logs to SIEM platforms like Splunk or elastic stack for centralized monitoring.

Key metrics to monitor:

• Discovery success rates: Percentage of servers successfully scanned per cycle
• Authentication failures: Credential expiration or permission changes
• Network timeouts: Firewall or connectivity issues preventing discovery
• Resource utilization: Discovery client CPU, memory, and storage usage

Set up alerts for discovery success rates below 95% - this indicates systematic issues that need immediate attention.

Essential Resources for Scale Operations:

• Discovery Client Performance Tuning - Configuration best practices for large environments
• Enterprise Migration Architecture - Multi-phase planning approach for complex migrations
• Credential Management Guide - Security controls and rotation strategies
• Network Dependencies Analysis - Planning integration points and mapping
• Cloud Migration Best Practices - Organizational readiness and validation techniques
• Discovery Client Installation Process - Step-by-step deployment instructions
• Discovery Client Installation Requirements - System requirements and network planning
• Discovery Client Collection Methods - WMI, SSH, and credential configuration
• Start Asset Discovery - Server and VM discovery configuration
• Google Cloud Security Best Practices - Enterprise security configurations and controls
• Migration Center Service Perimeter - VPC Security Controls for enterprise environments
• Disconnected Environment Support - Air-gapped network deployment

When Standard Solutions Don't Work

After getting burned by Migration Center in production more times than I can count, you develop a sixth sense for what's going to break at 2 AM during go-live. Google's docs are great if your environment was built yesterday by following best practices. The rest of us deal with legacy configurations that would make a consultant weep, custom security policies that block everything, and applications that were architected by someone who clearly hated their job.

Deep Troubleshooting with Log Analysis

Discovery Client Logging Architecture

Discovery client spits out logs in 4 different places because Google loves making troubleshooting fun. These logs are your only friend when things go sideways at 3 AM and you're trying to explain to management why the $2M migration project is stuck.

Log locations and purposes:

• Application logs: C:\ProgramData\Google\mcdc\logs\application.log - High-level discovery operations
• Collection logs: C:\ProgramData\Google\mcdc\logs\collection.log - Guest-level scanning details
• Upload logs: C:\ProgramData\Google\mcdc\logs\upload.log - Migration Center API communication
• Database logs: C:\ProgramData\Google\mcdc\logs\database.log - Local data storage operations

The log forwarding to Cloud Logging feature introduced in version 5.3.5.7 helps with centralized monitoring, but local log analysis is still required for detailed troubleshooting.

Decoding Cryptic Error Messages

Migration Center error messages are designed by someone who clearly never had to debug this shit in production. As of September 2025, they've been "improving" error messages but it's like putting lipstick on a pig. Here's what the errors actually mean:

"Authentication failed" - Multiple Root Causes:

• Credential expiration: Domain passwords rotated without updating discovery client (happens every 90 days if you follow security best practices)
• Permission creep: Service account permissions modified by security team without notification to migration team
• Network timeouts: Firewall rules blocking authentication traffic (particularly UDP 88 for Kerberos)
• Time skew: Domain controller time synchronization issues affecting Kerberos (more than 5 minutes of drift will kill authentication)

Debug approach: Check Windows Event Logs on both discovery client and target servers for security audit events. Look for event ID 4625 (failed logon) with detailed failure reasons. Pro tip: 90% of authentication failures are because someone changed the service account password and forgot to update the discovery client. The other 10% are time synchronization issues that will drive you insane - especially in virtualized environments where NTP drift is common.

"Connection timeout" - Not Always Network Issues:

• Resource exhaustion: Target server running out of memory or CPU
• Antivirus interference: Endpoint protection blocking WMI or SSH connections
• Windows Firewall changes: Group Policy updates modifying firewall rules
• SSH configuration drift: Server hardening scripts disabling SSH access

Debug approach: Test connectivity manually from discovery client to target server using the same protocols. Use telnet server.domain.com 22 for SSH and Test-NetConnection PowerShell cmdlet for WMI ports.

Database and Storage Issues

Discovery Client Database Corruption

The SQLite database that stores discovery data can become corrupted in several scenarios, particularly in environments with frequent reboots or storage performance issues.

Corruption symptoms:

• Discovery client UI shows "Database is locked" errors
• Scans appear to complete but no data appears in Migration Center
• Discovery client service fails to start with database-related errors
• Export operations fail with SQLite error messages

Recovery procedure:

## Stop discovery client service
Stop-Service \"Migration Center Discovery Client\"

## Backup corrupted database
Copy-Item \"C:\ProgramData\Google\mcdc\data\discovery.db\" \"C:	emp\discovery_corrupted.db\"

## Use recovery command (available in CLI versions 2.0+)
& \"C:\Program Files\Google\Migration Center Discovery Client\mcdc.exe\" recover-db

## If recovery fails, delete database and rescan
Remove-Item \"C:\ProgramData\Google\mcdc\data\*\" -Force
Start-Service \"Migration Center Discovery Client\"

When Your Storage Array Hates Discovery Client

Put discovery client on slow enterprise storage and watch it die a slow, painful death. The symptoms are subtle - UI gets sluggish, scans mysteriously incomplete, but no obvious errors. I've spent weeks debugging "network issues" that turned out to be a 7200 RPM drive from 2015. SQLite starts throwing "database is locked" (SQLITE_BUSY error code 5) when disk I/O latency exceeds 200ms. Fun fact: the September 15, 2025 release added AI-powered software detection, but if your storage can't keep up, you won't see any of those fancy insights anyway.

Performance indicators:

• Database operations taking >5 seconds: Check disk I/O latency on discovery client server
• Incomplete VM collection: Storage timeouts during large vCenter inventory operations
• UI freezing during report generation: Database queries timing out due to storage latency

Mitigation strategies:

• Move discovery client to local SSD storage instead of network-attached storage
• Increase discovery client VM resources: 8GB RAM minimum for large environments
• Separate database and application storage: Use different drives for logs vs. data

VMware Integration Edge Cases

vCenter API Limitations in Large Environments

VMware vCenter has API rate limiting and resource constraints that aren't well documented but become apparent when scanning large environments with thousands of VMs.

vCenter performance issues:

• API throttling: vCenter limits concurrent API connections from discovery client
• Memory exhaustion: Large inventory queries can consume significant vCenter memory
• Database locks: Heavy API usage can cause vCenter database performance issues
• Network timeouts: Complex cluster configurations with slow storage response

Optimization approach:

## Recommended vCenter scanning schedule for large environments
Peak Hours (8 AM - 6 PM):
  - Disable automated inventory collection
  - Manual scans only for critical issues
  
Off Hours (6 PM - 8 AM):
  - Enable automated collection
  - Stagger scanning across multiple vCenters
  - Limit concurrent VM guest collections to 10

Custom vSphere Configurations Breaking Discovery

Enterprise VMware environments often have custom configurations that automated discovery tools don't handle gracefully.

Common configuration issues:

• Distributed virtual switches: Complex network configurations confusing dependency mapping
• Custom VM attributes: Non-standard metadata fields causing collection failures
• Resource pools with strict limits: VM performance data skewed by resource constraints
• vMotion policies: VM location changing during collection causing incomplete data

Workaround strategies:

• Export RVTools data manually: Use RVTools import for complex environments
• Supplement with CSV data: Import additional VM metadata through manual data tables
• Schedule discovery during change freezes: Avoid scanning during maintenance windows with active vMotion

Network Dependency Mapping Challenges

The Reality of Network Discovery

The network dependencies feature introduced in version 6.3.0 collects network statistics and open ports, but it has significant limitations in enterprise environments with complex network architectures.

Network discovery blind spots:

• Load balancer traffic: Connections through F5, Citrix NetScaler appear as single connections
• Proxy server mediation: Applications communicating through proxy servers show proxy dependencies, not actual endpoints
• Encrypted protocols: SSL/TLS connections don't reveal application-level dependencies
• Batch job dependencies: Scheduled tasks that only run monthly or quarterly
• Database connection pooling: Middleware masking actual database connection patterns

Enhanced dependency mapping approach:

1. Combine automated discovery with application team interviews: Network data provides the foundation, but human knowledge fills gaps
2. Review application documentation: Architecture diagrams, deployment guides, and configuration management databases
3. Analyze application logs: Look for connection patterns, error messages, and integration points
4. Monitor during different time windows: Capture weekend batch jobs, month-end processing, and seasonal workloads

Cost Estimation Accuracy Issues

Why Migration Center Cost Estimates Are Fantasy Fiction

Migration Center's cost estimates are consistently wrong by 40-60%, and it's not random - it's systematically optimistic in ways that will get you fired if you trust them for budget planning.

Systematic underestimation factors:

Network costs underestimated by 60%: Migration Center assumes minimal egress traffic, but enterprise applications have significant east-west traffic patterns. Database replication, backup transfers, and integration flows generate substantial network costs.

Learning curve tax not included: The estimate assumes you'll nail rightsizing on day one. In reality, everyone over-provisions by 30-50% because nobody wants to be the person who undersized the production database. Then it takes 18 months to optimize because other priorities always come up.

Migration tool costs excluded: Database Migration Service, VM Migration, consulting fees, and training costs add $50-100K to typical enterprise migrations.

Operational overhead underestimated: New monitoring tools, security controls, and compliance requirements increase operational costs beyond the infrastructure estimates.

What you should actually budget:

Migration Center says: $47,000/month (adorable)
+ Network reality check (1.6x): $75,200/month
+ Over-provisioning safety net (40%): $105,280/month  
+ Migration tools & consulting: $25,000/month
+ Operational shit they forgot (30%): $137,000/month
= Real budget: $140,000/month for first year, then maybe $90K after optimization

September 2025 Update: Google finally added the "granular Compute Engine preferences" feature on September 15th. Now you can balance "latest technology vs cost" or "prioritize lowest price". Cool in theory, but it just gives you more knobs to turn while the underlying cost estimates are still fantasy numbers. I tested this last week - same broken estimates, just with prettier configuration options.

License Cost Calculation Errors

The Microsoft licensing calculator introduced in version 6.3.1 has assumptions that don't match enterprise licensing realities.

Common licensing miscalculations:

• Enterprise Agreement discounts: Migration Center uses list pricing, not negotiated EA rates
• SQL Server core licensing: Estimation assumes optimal core allocation, not actual deployment patterns
• Windows Server datacenter licensing: Doesn't account for existing datacenter licenses that could be transferred
• Software Assurance benefits: Migration Center doesn't factor in existing SA coverage

Accurate licensing approach: Export the detailed pricing CSV file and have your Microsoft licensing team review the assumptions. The generic calculations are useful for initial estimates, but enterprise licensing requires specialist review.

Security and Compliance Edge Cases

Discovery in Highly Regulated Environments

Financial services, healthcare, and government organizations have security requirements that standard Migration Center deployment doesn't address.

Common security challenges:

• Air-gapped networks: Discovery client can't communicate with Google Cloud APIs
• Privileged access management: Discovery credentials must be managed through enterprise PAM tools
• Data sovereignty: Collected data must remain in specific geographic regions
• Audit logging: All discovery activities must be logged for compliance review

Compliance-compatible deployment:

• Use offline export functionality: Disconnected environment support for air-gapped networks
• Deploy regional discovery clients: Keep data in required geographic boundaries
• Integrate with SIEM platforms: Forward all discovery logs to enterprise security monitoring
• Document discovery scope: Create detailed records of what data is collected and where it's stored

Essential Troubleshooting Resources:

• Discovery Client Troubleshooting - Official error resolution and debugging steps
• CLI Troubleshooting Guide - Command-line diagnostics and recovery procedures
• Migration Architecture Patterns - Enterprise-scale best practices and design patterns
• Database Recovery Commands - SQLite corruption resolution and data recovery
• Migration Center Login Troubleshooting - Authentication and access issues
• VMware vCenter API Documentation - Understanding vCenter integration failures
• File Import Error Resolution - CSV and data import troubleshooting
• Database Migration Service Debugging - Migration connectivity and data issues
• Migration Center Support Cases - Creating and managing support requests
• Google Cloud Support API - Programmatic case escalation procedures
• Migrate to Virtual Machines Troubleshooting - VM migration specific issues
• Cloud Architecture Framework - Incident response and escalation procedures
• Peak Events Support - Critical event preparation and response