Map runtime dependencies, not just package dependencies
A dependency manifest tells you what is needed to build the application, but it does not describe everything required to operate it. Enterprise software may call databases, file servers, ERP or CRM APIs, identity providers, internal DNS, printers, hardware keys, and services reachable only from a fixed IP range. Some of these dependencies appear only during month-end processing, document generation, or an uncommon approval path. An application can therefore start successfully in a container and still fail when a particular business transaction reaches an unrecorded integration.
Build the dependency map from configuration files, environment variables, connection logs, scheduled jobs, and observed network traffic, then review it with the people who operate the system. For every dependency, record its owner, protocol, authentication method, timeout and retry policy, certificate rotation process, and expected behavior during an outage. If an external system lacks a stable interface or health signal, consider introducing an adapter before migration. Otherwise, containerization merely relocates the coupling while making it harder to see.
- Build dependencies: operating-system packages, runtime versions, fonts, native libraries, and compilation tools.
- Service dependencies: databases, queues, identity services, email gateways, third-party APIs, and internal business systems.
- Infrastructure dependencies: DNS, fixed addresses, firewall allowlists, certificates, shared storage, and time-zone assumptions.
- Operational dependencies: manual file drops, desktop shortcuts, server-side edits, schedulers, and undocumented handoff steps.
Classify state before choosing where it should live
Containers are normally replaceable, so an application cannot assume that its filesystem, hostname, or process instance will remain available. Separate authoritative state, temporary state, and reproducible data. Database records, uploaded source files, pending messages, and audit trails usually require durable storage. Caches, thumbnails, and compiled assets may be recreated. Working files require a closer decision: can a job safely restart from the beginning, or must it resume at an exact checkpoint? The goal is not to attach permanent storage to everything, but to give every data class an explicit lifecycle and recovery method.
Applications that store sessions, uploads, or scheduler progress locally often behave incorrectly when multiple replicas are introduced. A user may lose a session, an uploaded file may exist on only one replica, or several containers may run the same scheduled task. Typical remedies include moving sessions to a shared service, storing files in object storage, and tracking work through a database or message broker. These choices add latency, cost, and new failure modes, however. Select storage according to consistency needs, access patterns, data volume, recovery objectives, retention rules, and regulatory boundaries rather than applying one architecture to every workload.
- Durable state: transactions, configuration versions, original uploads, unfinished work, and audit records.
- Ephemeral coordination: sessions, locks, queue offsets, and temporary results whose loss is acceptable.
- Reproducible data: caches, index replicas, thumbnails, intermediate reports, and generated deployment assets.
- State to eliminate: embedded passwords, long-lived keys, and sensitive data written into images or logs.
Test lifecycle, concurrency, and failure behavior
Many legacy applications were designed for one server, one process, and a fixed startup sequence. A container platform may reschedule them, restart them quickly, or run several replicas at once. Confirm that initialization is repeatable, database migrations cannot race, and scheduled jobs use leader election or distributed locking where required. Transaction handlers, queue consumers, and webhooks should be idempotent so that a retry does not duplicate a payment, notification, or downstream update. Increasing a startup delay is not a reliable substitute for handling an unavailable dependency.
Shutdown behavior matters just as much. After receiving a termination signal, a workload should stop taking new work, complete or safely return in-flight tasks, close connections, and exit within the platform's grace period. Distinguish liveness, readiness, and startup checks: a running process is not necessarily ready for traffic, and a temporarily unavailable dependency does not always justify restarting the application. If every check calls the same endpoint, a slow database can cause a restart cascade that makes recovery harder.
Testing should go beyond proving that an image starts on a developer laptop. Terminate a container during a request, interrupt an external service, restart a worker halfway through a job, and launch multiple replicas concurrently. Then inspect for lost writes, duplicated operations, repeated notifications, stale locks, and incomplete files. These controlled failures expose assumptions that must be corrected before production orchestration can be trusted.
Use recoverability to set migration order and ownership
Not every component needs to move at once. Stateless APIs, front ends, and replayable background workers are often good early candidates. Components tied to local files, dedicated hardware, obsolete database drivers, or manual operator actions may need refactoring, temporary retention on existing hosts, or isolation behind a stable interface. The useful decision criterion is whether the component can fail, be rebuilt, and recover predictably—not merely whether an image can be produced.
Before migration, each service should have an image-version policy, configuration and secret-management approach, tested backup and restore procedure, logs and metrics, capacity baseline, and explicit rollback path. Plan data migrations separately from application deployment, and determine whether old and new versions can coexist during rollout. A code rollback has little value if the previous version cannot read the modified schema. Finally, application, platform, security, and business-operations teams must agree on ownership. Container orchestration can improve delivery consistency, but it cannot resolve ambiguous data stewardship or recovery duties. When a system spans LINE, ERP, CRM, cloud services, and private networks, an integration team can help validate the dependency map and failure drills before platform choices become expensive commitments.