Migration - Upgrades

How to Move ColdFusion Logs and Metrics to a New Server

by Aaron Longnion
10 min read
Contents show

Why moving ColdFusion logs and metrics matters

Logs and operational metrics are your ground truth for Troubleshooting, Performance tuning, capacity planning, Security auditing, and Compliance. When you shift ColdFusion to a new server—whether for an OS refresh, Scaling, or Cloud Migration—you must bring along the history (where appropriate) and ensure the new host starts emitting data in the same structured, searchable way. Done well, you’ll preserve Audit trails, retain observability continuity, and avoid painful blind spots during and after cutover.

Prerequisites / Before You Start

  • Inventory and versions

    • ColdFusion distribution and version (Adobe ColdFusion 11, 2016, 2018, 2021, 2023; or Lucee 5.x/6.x).
    • Application server/runtime (bundled Tomcat version) and JDK version.
    • Log framework: Adobe ColdFusion now uses Log4j2; older versions used Log4j 1.x. Lucee uses Log4j (varies by bundle), plus Tomcat’s JULI for container logs.
    • Monitoring/metrics stack: Adobe PMT (Performance Monitoring Toolset), FusionReactor, New Relic, Datadog, Prometheus JMX exporter, Elastic Stack, Splunk, Graylog, SIEM, etc.

  • Log and metric sources you rely on

    • ColdFusion application logs: application.log, exception.log, scheduler.log, server.log, Audit.log, etc.
    • ColdFusion console/launcher logs: coldfusion-out.log.
    • Tomcat/container logs: catalina.out, localhost_access_log.* (AccessLogValve), host-manager/manager logs.
    • Web server connector logs (if IIS/Apache connectors are used).
    • OS-level logs (Windows Event Log, syslog) if ingested.
    • Any custom loggers (e.g., RollingFileAppender writing JSON).

  • Default locations (validate on your installation)

    • Adobe ColdFusion:
      • Windows: C:\ColdFusion2021\cfusion\logs\
      • Linux: /opt/ColdFusion2021/cfusion/logs/
      • Tomcat: [cf_home]/cfusion/runtime/logs/
    • Lucee (varies with installer):
      • Linux: /opt/lucee/tomcat/lucee-server/context/logs/ and /opt/lucee/tomcat/logs/
      • Windows: C:\lucee\tomcat\lucee-server\context\logs\ and C:\lucee\tomcat\logs\

  • Access and permissions

    • Administrative access to old and new servers.
    • File permissions to read old logs and write to new locations.
    • Network access to your log/metrics aggregator(s).

  • Backups and retention

    • Full backup of old log directories and relevant monitoring agent directories.
    • Snapshot/backup of monitoring data stores (if self-hosted), e.g., Elasticsearch/InfluxDB/PostgreSQL depending on the tool.
    • Know your retention policy (days/size/legal/Compliance).

  • Security and compliance

    • Verify Log4j2 is patched to a safe version (e.g., 2.17.x+ for Java 8) to avoid CVEs.
    • Validate encryption-in-transit for log shipping (TLS for Beats/Syslog/HTTP).
    • Confirm PII/token masking rules exist and will carry over.

  • Change management

    • Freeze window, rollback criteria, communication plan.
    • Test plan for parsing and dashboard validation in your SIEM/observability tool.

  • Time sync

    • Ensure both servers use the same time source (NTP) and timezone strategy (UTC recommended) to avoid skew.
See also  How to Migrate from ColdFusion to Lucee (Open Source)

Migration strategy overview

  1. Decide what you will migrate:
    • Historical logs (files).
    • Current/ongoing logs (by relocating file outputs and log-shipping agents).
    • Historical metrics (often not migrated if SaaS-backed; if self-hosted, plan Data export/import).
  2. Align formatting and structure:
    • Confirm log formats (patterns/JSON) and fields remain consistent to avoid breaking parsers and dashboards.
  3. Migrate in a staged way:
    • Dry run to a staging server.
    • Parallel-logging validation during a canary period.
  4. Cut over:
    • Switch traffic to the new server only after you see new logs/metrics flowing and validated.

Step-by-step Migration guide

1) Freeze and document the current state

  • Export ColdFusion Administrator logging settings:
    • Max file size, rollover count, log levels, log directories, SMTP/Email appender (if any).
  • Identify log4j2.xml (Adobe CF) or logging.properties/log4j.xml (older/Lucee variants) location and back it up.
  • Snapshot your current log-shipping agent configs (Filebeat/Winlogbeat/Fluent Bit/Fluentd/Logstash forwarder):
    • Paths, multiline rules for stack traces, tags, index/app names, TLS certificates.

Example: backup (Linux)

sudo tar -C /opt/ColdFusion2021/cfusion -czf cf-logs-and-configs.tgz logs lib/log4j2.xml
sudo tar -C /etc -czf beats-configs.tgz filebeat/ fluent-bit/

2) Copy historical logs to the new server

  • Use rsync/robocopy/scp to transfer. Preserve timestamps and permissions where possible.

Linux to Linux:

rsync -avz –progress /opt/ColdFusion2021/cfusion/logs/ \
newserver:/opt/ColdFusion2021/cfusion/logs-archive/
rsync -avz /opt/ColdFusion2021/cfusion/runtime/logs/ \
newserver:/opt/ColdFusion2021/cfusion/runtime/logs-archive/

Windows to Windows:

robocopy C:\ColdFusion2021\cfusion\logs \newserver\C$\ColdFusion2021\cfusion\logs-archive /E /COPY:DAT
robocopy C:\ColdFusion2021\cfusion\runtime\logs \newserver\C$\ColdFusion2021\cfusion\runtime\logs-archive /E /COPY:DAT

  • Keep historical logs in a separate “-archive” folder to avoid confusing live ingestion.

3) Install/upgrade ColdFusion on the new server

  • Match the CF version and cumulative hotfix/update level to ensure log categories and patterns remain consistent.
  • Apply security updates (especially log4j2). Verify Java version compatibility.
  • Recreate instances (cfusion vs. named instances) to mirror the old topology.

4) Recreate logging Configuration on the new server

  • Adobe ColdFusion (log4j2.xml)
    • Typical location: [cf_home]/cfusion/lib/log4j2.xml
    • Ensure RollingFileAppender settings match old server’s pattern and rotation.

Example: Log4j2 RollingFileAppender (CF 2021/2023)


















  • ColdFusion Administrator
    • Debugging & Logging > Logging Settings: confirm the log directory, rotation size, and retention values align with policy.
  • Tomcat access logs (if you rely on them)
    • server.xml AccessLogValve should be consistent with old patterns (used by parsers):

<Valve className=”org.apache.catalina.valves.AccessLogValve”
directory=”logs”
pattern=”%h %l %u %t "%r" %s %b %D”
prefix=”localhost_access_log” suffix=”.txt” rotatable=”true”/>

Tip: Prefer ISO8601 timestamps and JSON format if your aggregator parses JSON natively. It improves search and reduces GROK complexity.

5) Reconfigure and test log shipping from the new server

  • Filebeat (example) for Adobe CF logs:

filebeat.inputs:

  • type: log
    enabled: true
    paths:
    • /opt/ColdFusion2021/cfusion/logs/*.log
    • /opt/ColdFusion2021/cfusion/runtime/logs/*.log
      multiline:
      pattern: ‘^\d{4}-\d{2}-\d{2}T’
      negate: true
      match: after

output.logstash:
hosts: [“logstash.mycorp.local:5044”]
ssl:
certificate_authorities: [“/etc/pki/tls/certs/ca.crt”]

  • Windows Winlogbeat addition (if you collected Windows Event Logs previously):
    • Ensure the same channels and event IDs are enabled.
  • Fluent Bit example:

[INPUT]
Name tail
Path /opt/ColdFusion2021/cfusion/logs/.log
Tag cf.
Multiline On
Parser_Firstline multiline_java

[OUTPUT]
Name es
Match cf.*
Host es01
Port 9200
Logstash_Format On
tls On

  • Validate TLS and index naming conventions. Keep tags/fields (env, app, instance) consistent with the old server.

6) Handle metrics collectors and APM agents

  • Adobe Performance monitoring Toolset (PMT)
    • If you run PMT server separately, point the new CF server’s PMT agent to the PMT endpoint.
    • For historical PMT data, follow Adobe guidance to back up and restore the PMT datastore. If you can’t preserve history, document the gap and keep the old PMT instance read-only for reference.
  • FusionReactor / New Relic / Datadog
    • Install the agent on the new server and apply the same application/service name.
    • Confirm license keys and hostname settings. Some licenses are tied to hostnames; plan reallocation.
    • Validate dashboards and alert policies still target the correct entity/service.
  • Prometheus JMX exporter
    • If scraping Tomcat/JVM/JMX metrics, update scrape configs with the new host/IP and target labels.
See also  How to Train Teams for Post-Migration ColdFusion Support

7) Migrate or mount historical logs for searchability (optional)

  • If your SIEM/ELK needs to re-index old logs, ingest the “-archive” directory using a one-time job.
  • Set fields like event.original_timestamp to preserve the original time. Ensure you don’t double-ingest historical data.
  • Alternatively, keep the old logs on low-cost storage and search them only when needed to save index costs.

8) Cut over traffic and observe

  • Switch DNS/load balancer to route traffic to the new server.
  • Watch ingestion dashboards: volume per minute, error rates, parsing errors, and alert triggers.
  • Keep the old server in standby to cross-check logs if anything looks off.

9) Decommission old logging paths safely

  • After validation and retention window requirements are met, archive and purge old logs securely.
  • Remove old agents/forwarders and revoke credentials/keys.
  • Update runbooks and architectural diagrams to reflect the new logging/metrics topology.

Risks, common issues, and how to avoid them

  • Parsing breaks due to format drift

    • Risk: Slight changes in timestamp patterns or field order break Logstash/Grok or SIEM pipelines.
    • Avoid: Keep the same log4j2 patterns. Use JSON logs where possible. Add robust multiline rules for Java stack traces.

  • Timezone and clock skew

    • Risk: Events appear out of order or misaligned with alerts.
    • Avoid: Use UTC; ensure NTP is configured. Normalize timestamps at ingestion.

  • Permissions and file handles

    • Risk: Log files not written due to ownership/SELinux; shipping agents can’t read files.
    • Avoid: Confirm user/group permissions. Test by tailing logs as the service account. Adjust SELinux context if applicable.

  • Duplicate ingestion or gaps

    • Risk: Duplicates inflate counts; gaps erode visibility.
    • Avoid: Separate “-archive” paths from live inputs; tag historical replays; use fingerprinting or file state registries (e.g., Filebeat registry) carefully.

  • Log rotation misconfigurations

    • Risk: Unbounded disk growth or aggressive rotation causing loss.
    • Avoid: Set size/time rotation and max backups. Monitor disk usage. Compress archives.

  • Security regressions

    • Risk: Unencrypted log shipping or exposure of PII tokens.
    • Avoid: Enforce TLS, certificate pinning, and masking rules. Review security policies.

  • Agent Licensing/host identity

    • Risk: APM agent or PMT not accepting data due to license or entity mismatch.
    • Avoid: Reallocate licenses, confirm hostnames/tags, and rebind application naming conventions.

  • Log4j vulnerabilities

    • Risk: Old log4j versions reintroduced on the new host.
    • Avoid: Verify patched versions in the new installation. Remove extraneous vulnerable jars.

Post-migration Checklist

  • ColdFusion

    • Application, exception, scheduler, and Server logs are created in the expected directory.
    • Log rotation occurs and archived files appear correctly.
    • ColdFusion Administrator > Debugging & Logging settings match policy.
    • Any CF mail/appender alerts function as expected.

  • Tomcat

    • Access logs are present and rotated with correct format.
    • catalina.out (or equivalent) is not growing uncontrollably; consider limiting/rotating if needed.

  • Log shipping

    • Agents are running and healthy (service status green).
    • No backlog or excessive buffer usage.
    • Parsing shows correct fields; stack traces are properly multiline-merged.
    • Dashboards show continuous data without gaps since cutover.

  • Metrics/APM

    • New server appears in PMT/APM with the correct app and environment tags.
    • Throughput, error rate, response time, JVM metrics present and sane.
    • Alerts fire on test conditions (induce a benign 404 spike or a synthetic check).

  • Security and compliance

    • TLS in use end-to-end.
    • PII masking verified in sampled events.
    • Access controls applied to log search tools.

  • Operations

    • Runbooks updated to reflect locations, commands, contacts.
    • Old server prepared for decommission according to policy.
    • Backups and retention tasks scheduled on the new host.
See also  How to Move ColdFusion Apps to a New Domain or Host

Configuration snippets you can adapt

Example: Move ColdFusion log directory (via Log4j2 and CF Admin)

  • Update log4j2.xml fileName paths to a new volume, e.g., /data/cf-logs/.
  • In ColdFusion Administrator, set the log directory to match that volume.
  • Restart ColdFusion services to apply.

<RollingFile name=”ServerLog”
fileName=”/data/cf-logs/server.log”
filePattern=”/data/cf-logs/archive/server-%d{yyyy-MM-dd}-%i.log.gz”>
…

Example: Systemd unit override to set environment variables (Linux)

If you rely on ${sys:coldfusion.rootDir}, confirm the service exports it.

sudo systemctl edit coldfusion2021

[Service]
Environment=”coldfusion.rootDir=/opt/ColdFusion2021/cfusion”

Then:

sudo systemctl daemon-reload
sudo systemctl restart coldfusion2021

Example: Rsyslog shipping of Tomcat access logs

/etc/rsyslog.d/cf-tomcat.conf

module(load=”imfile”)
input(type=”imfile”
File=”/opt/ColdFusion2021/cfusion/runtime/logs/localhost_access_log.*.txt”
Tag=”cf-access”
Severity=”info”
Facility=”local6″)

. @@logs.example.com:6514;RSYSLOG_SyslogProtocol23Format

Example: Grok pattern for CF log with ISO timestamp

%{TIMESTAMP_ISO8601:timestamp} [%{DATA:thread}] %{LOGLEVEL:level} %{JAVACLASS:logger} – %{GREEDYDATA:message}

Optimization tips

  • Normalize format early
    • Prefer JSON logs for application and platform logs to reduce downstream parsing complexity.
  • Set consistent tags/labels
    • env, app, service, instance, region. Use these in routing and alerting.
  • Use canaries
    • Before cutover, run the new server in parallel with a small percentage of traffic to test observability end-to-end.
  • Automate
    • Manage logging and shipping configs with Ansible/Chef/Puppet or Terraform for immutable consistency across nodes.
  • Storage Efficiency
    • Compress rotated files, and set tiered retention (hot-warm-cold). Consider object storage for long-term archives.

FAQ

How do I safely migrate historical logs without double-ingesting them?

  • Keep historical files in a clearly separate path (e.g., logs-archive) that is not part of your live Filebeat/Fluent Bit inputs. If you need to reindex, create a one-time “historical” pipeline with distinct index/fields and then disable it after completion.

Do I need to migrate Adobe PMT historical metrics?

  • Not necessarily. If PMT is self-hosted and you must retain history for compliance or baselining, back up and restore the PMT datastore following Adobe’s documentation. Many teams choose to keep the old PMT instance read-only for a time window and start fresh on the new server.

What about FusionReactor or SaaS APM histories?

  • Those are typically retained in the vendor’s cloud and tied to application name/account, not your server. Install the agent on the new host, reuse the same app name and license (as permitted), and the history stays accessible.

Why did my multiline stack traces break After migration?

  • Multiline rules often depend on the first-line timestamp pattern. If the new log pattern or timezone changed, the regex may fail. Update your multiline configuration to match the new pattern and verify with a sample stack trace.

Can I change log formats during migration (e.g., to JSON)?

  • Yes, but treat it as a separate, well-planned change. Update log4j2 appenders to output JSON, adjust parsers in your pipeline, and validate dashboards before cutover to avoid confusion.

About the author

Aaron Longnion

Aaron Longnion

Hey there! I'm Aaron Longnion — an Internet technologist, web software engineer, and ColdFusion expert with more than 24 years of experience. Over the years, I've had the privilege of working with some of the most exciting and fast-growing companies out there, including lynda.com, HomeAway, landsofamerica.com (CoStar Group), and Adobe.com.

I'm a full-stack developer at heart, but what really drives me is designing and building internet architectures that are highly scalable, cost-effective, and fault-tolerant — solutions built to handle rapid growth and stay ahead of the curve.

View all posts

You may also like