A working home page is not enough to declare a blog migration complete. Articles may contain older text, images may be missing, or only the English links may point somewhere unexpected. After moving Nole IT from a NAS to Oracle, we checked article content, public routes, media, and backups as separate evidence.
This record combines migration artifacts retained on 2026-09-13 KST with a read-only check of the migrated site on the same day. It does not invent incidents or a before-and-after speed comparison. Production data was not restored again, and production settings were not changed for these checks.
Establish which server and content you are reading
The current CMS is WordPress 7.1. Oracle runs Nginx, PHP-FPM, and MariaDB, with public delivery through Cloudflare. Existing Korean article URLs and English /en/ URLs were retained. The former NAS used Docker-based WordPress; that historical description was not treated as the current server configuration.
We did not rely on an origin-identification header alone. Through administrative access, we read the content hashes for public posts and pages from the Oracle WordPress database and compared them with stored content returned by the current WordPress REST API. All 44 posts and 22 pages matched, for 66 records in total. This establishes agreement between the database and API, not technical correctness of every sentence.
The local manuscripts also had a discrepancy. Of 44 public articles, 42 matched local HTML after trimming leading and trailing whitespace. The Korean and English OpenWrt build-diagnosis articles differed. Republishing a repository file in that situation could erase changes already present on the live site. The review manuscripts therefore start from content verified against Oracle.
Check individual URLs and missing paths alongside the home page
| Target | Observed result | Interpretation |
|---|---|---|
nole.co.kr/, www.nole.co.kr/ | Final destination https://it.nole.co.kr/, HTTP 200 | The primary entry routes reach the IT home page |
| Korean and English home pages | HTTP 200 for each | Both language entry points respond |
| 44 existing public articles | Full content collected and compared as 22 language pairs | Counts were checked alongside actual content |
| Nonexistent IT path | HTTP 404 | A missing article is not hidden behind a successful home response |
| The same nonexistent path on the primary domain | Redirected to the same IT path, then HTTP 404 | Home routing and missing article handling are distinct |
You can begin by recording the final public response with commands such as these. The second URL is the nonexistent path chosen for this check. curl can finish with exit code 0 while the HTTP response is 404, so read command completion and HTTP status separately.
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' https://nole.co.kr/
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' https://it.nole.co.kr/no-such-content-audit-20260913/These are observations at one point in time. They do not establish actual Google Search or advertising crawler access, or rule out intermittent failures. We also did not request every historical product URL from the closed shopping site, so the state of that complete set remains unknown.
Separate image display from file identity
We fetched the 2 original images registered in the migration records from their current public URLs and compared SHA-256 hashes. Both returned HTTP 200 and matched the preserved source-file hashes. This does not validate every derived thumbnail size or display in every browser.
Even an identical file is invisible to a reader if a page points to the wrong address. Links and actual rendering therefore remain separate checks. Similarly, a working English home page is not enough: each article’s self-canonical and counterpart-language links were compared. The 2 language URLs count as one editorial case.
A backup file and a successful restore are different results
After locating the migration database backup, we restored it into a disposable MariaDB 11.4.13 instance on a development host separate from production Oracle. It had no published port or external network connection. SQL and authentication material were not included in the article or public attachments. The test database container and data volume were removed afterward.
database import: exit 0
verification query: exit 0
public posts: 44
draft posts: 234
public pages: 22
draft pages: 6This shows that the retained SQL could be read into a separate database and recover those publication states. It does not establish recovery of the complete web server, plugin functions, email, or scheduled jobs. Restoring a migration-time SQL snapshot over newer data can erase subsequent changes. A real recovery requires reconciling current changes and the timestamps of database and file backups first.
The earlier migration record contains NAS-to-Oracle content and response comparisons and source-file checks. We do not describe those earlier operations as having been performed again during this audit. In particular, one migration backup does not constitute a regular offsite backup system. Keep backup locations and access controls private, and plan independent restore checks.
The server can move while the About page stays behind
Although server responses worked, the Korean and English About pages still described the site as currently running on a NAS. Dated observations from the old NAS should remain as historical records, but a present-tense description of the operating environment should match the actual deployment. That is why migration verification also includes reading those descriptions, beyond checking data and links.
This check establishes current content agreement, primary entry routes, 2 original images, and the limited database-restore result. It does not establish pre-migration performance or functionality in every user environment. Recording these boundaries makes it clearer which evidence to collect when a later problem occurs.
If a plugin prevents administrative commands from loading, continue with WordPress bootstrap failures and recovery boundaries. If public and origin responses differ, see separating Cloudflare and origin responses.
Headroom for follow-up checks on a 1 GB production server
A separate observation on 2026-09-14 found 954 MiB of RAM and 1 GiB of swap on this Oracle instance. At the start, free -m showed 67 MiB free but 444 MiB available. Linux MemAvailable estimates memory available for new work, including some reclaimable cache. This is why neither abandoning all checks based only on free memory nor counting every cached byte as spare capacity is a sound starting point.
free -m
vmstat 1 3
systemctl is-active nginx php8.3-fpm mariadb cloudflaredThe verified configuration used PHP-FPM ondemand, at most 2 children, a 192 MiB PHP-FPM memory limit, 64 MiB OPcache, and a 96 MiB InnoDB buffer pool. The child limit is not the current process count, and the buffer pool is not the database’s entire resident memory. A separately invoked PHP CLI reported a default memory limit of -1. Instead of assuming that FPM settings applied to CLI checks, subsequent read processes explicitly used php -d memory_limit=128M. Production service limits were not increased.
After compilation and smaller checks, 381 unit and mock-service tests ran sequentially in a separate network namespace without production credentials. That particular run took about 39.7 seconds and all tests passed. Sampling every 0.2 seconds observed a minimum server MemAvailable of about 360.3 MiB and a peak summed RSS of about 81.8 MiB for the validation process group. Summed RSS can count shared memory more than once, and sampling can miss short peaks. These figures are not whole-server memory usage, the requirements of another test suite, or WordPress traffic capacity.
For this run, broader checks were not started below 200 MiB MemAvailable, and the validation task alone was to stop below 128 MiB during execution. These are conservative budgets for this run, not official WordPress requirements or a safety guarantee. The first vmstat row is cumulative, so also inspect the subsequent interval rows. Distinguish allocated swap from continuing swap in/out, and stop checks to investigate new OOM records or response delays. Do not stop the web or database service to create test headroom or deliberately reproduce memory exhaustion.
This follow-up is a limited observation of running validation tools alongside production. It did not restore the production database, test browser rendering, or compare pre- and post-migration speed. The Linux /proc descriptions of MemAvailable and RSS and PHP-FPM process management settings were checked on 2026-09-14.
Evidence and scope
The numbers and results come from retained migration artifacts, read-only production queries, and an isolated database restore on 2026-09-13. General backup scope is compared with the WordPress backup guidance; language links are compared with Google’s localized-page guidance. Assessing a speed improvement requires separate before-and-after measurements collected under the same conditions.