An application migration assessment for a permitting system finds hard-coded IP addresses to an on-premises file server and a legacy license host, blocking a clean early rehost. What should the assessment outcome emphasize?
Select an answer to reveal the explanation.
Short Explanation
Hard-coded IPs are tripwires. Call them blockers, fix DNS or config, and sequence the dependency—don’t assume Elastic IPs will magically keep the old street addresses alive.
Full Explanation
An application migration assessment for a permitting system that finds hard-coded IP addresses to an on-premises file server and a legacy license host should treat those findings as migration blockers or wave risks. Remediation—DNS and name services, configuration externalization, or sequenced dependency moves—must precede an early rehost so the city does not cut over into broken name and license paths. Ignoring hard-coded IPs because Elastic IPs will preserve every address after migration automatically fails conceptually: Elastic IPs do not magically rewrite application literals pointing at on-premises servers, nor do they preserve arbitrary private IPs across environments. Proceeding with rehost immediately and fixing name resolution only if production breaks fails safe-migration practice for citizen permitting. Classifying the findings as cosmetic because IP literals are equivalent to DNS on AWS fails because literals bypass DNS and break when addresses change. Exam caveat: hard-coded IPs are classic migration blockers requiring remediation before early rehost. Operational check: scan configs for literals, replace with DNS names, migrate or dual-run file and license dependencies in sequence, retest permitting flows in a pilot account, then schedule rehost.