Exporting the entire old station into a package and then importing it, will the attachments fall outside?
WordPress migration plugin exports the entire site into a package, will the attachments be lost when importing into the new system? There are two cases: moving the station within the same system, the attachments in the package generally follow; cross-system import, whether the data in the package can be recognized by the new system depends on whether the fields and directory structure correspond. It is usually the second link that causes the attachments to stay outside, not the export link.
What does each import route take away?
| Route | The content taken away | Key point | Suitable scenario |
|---|---|---|---|
| Package the entire site into one | Database, media files, templates, and extensions | Upload volume limit, whether the target system can recognize the package structure | Switching hosts or domains within the same system |
| Import in batches by table | Text and structured fields | Attachments need to be uploaded separately and matched | Content reconstruction, need to reorganize categories and fields |
| Import in bulk via compressed package | Documents with package resources | Naming conventions and directory agreements, matching cover images | The site map and resource directory are relatively standardized |
The advantage of the packaging route is completeness, putting databases, media files, themes, and extensions all into a single file; the disadvantages are also obvious: it is only non-destructive migration when the target end recognizes this structure, and when crossing to different content model systems, the data in the package needs to be re-placed in the fields.
The table route is reversed: the main text and custom fields can be aligned by column, and the structured information is controllable, but images and attachments are usually not in the table and need to be processed separately. Treating attachments as a separate batch of resources to export is a more common practice during cross-system migration.
Where is the upload limit stuck?
The most common restriction encountered in the packaging route is the file size. This limit is determined by the host rather than the plugin itself: the official instructions clearly state that the host company decides on the maximum file size that can be uploaded, so large backup packages may not be able to proceed along this route. The usual manifestation is that the upload fails halfway through or there is no response after submission, rather than an explicit error message.
Encounter this layer of limitation, there are three optional treatments: batch export, command line or other import entry, or first move the media files separately and then transfer the data. Which one to choose depends on the composition of the package, if the vast majority of the volume comes from media files, first synchronize the media directory directly to the resource directory of the target server, the remaining data part is often within the limit.
The correspondence relationship between the attachment and the main text reference
Will the attachment 'fall outside', ultimately depending on whether the references in the main text can still be parsed. Three corresponding relationships need to be confirmed one by one: whether the path of the resource directory is consistent with the target system; whether the absolute address or relative path is saved in the main text; whether the thumbnail and derived size need to be regenerated. When the path levels are inconsistent, the file is on the server but does not appear on the page, looking like the attachment is missing.
Before importing, do a sampling by type: several articles with images, articles with download attachments, and list pages with cover images and illustrations should be sampled. AnQiCMS supports batch importing in two forms: ZIP compressed packages and Excel tables. The interface provides an import/archive channel for importing document content and supports querying whether documents already exist by title. When importing repeatedly, it is recommended to check for duplicates first to avoid the same batch of content being written twice.
Three acceptance items after migration
The first item is accessibility: pull a batch of addresses from the site map and confirm that the return status matches the landing page. When the domain name changes, the 301 redirect of the old address should be mapped to the new address one by one, and the jump link should not be too long, nor should there be a dead link pointing to the old path.
The second item is data consistency: whether categories, tags, and custom fields are in place as expected, and whether sorting and filtering on the list page are still functional. The third item is the fallback ability: confirm that there is a recoverable backup on the target end, and retain the old site for a while, so that it can compare the original data when there is a missing content.
Before migrating, it's more convenient to do a small-scale trial run on the new system. First, try a few articles with attachments to confirm that the paths, fields, and images correspond correctly, and then proceed with batch import, which is the cheapest step on this path.
Common questions
The whole site package already contains images, why doesn't it show up after import?Common reasons include different path levels or naming conventions, or the absolute address of the old site is saved in the text. First, check if the file exists, and then check where the reference points.
Can table import carry attachments?The table carries text and fields, and attachments are generally uploaded as a separate batch of resources before matching. It is more stable to establish the matching relationship before batch importing than to replace the address after the fact.
Should the old site be retained?It is recommended to retain it for at least a period of time. The old site is the original basis for verification and rollback, and can also be used to supplement addresses when there are omissions in the jump mapping.