At a certain size a forum migration stops being a conversion problem and becomes a logistics one. The questions are how long the data takes to move, how much of it changes while it is moving, and how to prove nothing was lost when the counting itself takes hours.
A small forum is converted in a run and verified by inspection. A large one has to be moved in stages, reconciled by counting rather than by looking, and cut over inside a window whose length is set by how fast the data can be transferred and how much of it changes while that happens. Those are different problems, and the techniques that work at one size do not work at the other.
The migration is right and the practical question is how to execute it without a downtime members will notice.
It ran out of time, disk or patience, and you need a staged method rather than a faster machine.
You need the constraints established — transfer time, change rate, window length — before you decide whether the move is feasible.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Bulk data moves before the cutover, so the window covers only what changed in the meantime. On a busy community the change rate is the constraint that decides window length, and reducing it is more tractable than transferring faster.
Nobody inspects a million posts. Reconciliation is automated and per content type, and the automated counts become the only evidence the migration is complete — which means the counting has to be built as part of the importer rather than afterwards.
Media is frequently the larger part of a forum's stored data and the part held outside the database. A migration planned around the database size alone discovers the real volume at the point it has least room to react.
On a large community, an abandoned cutover means the work is repeated, the members have been disrupted for nothing, and the next attempt has less goodwill behind it.
Each of these is work we carry out, not an area we advise on.
Establishing what actually has to move and where it lives: database size by table, attachment and media volume including anything outside the database, and the change rate during a normal day. The shape of the data decides the method more than the total does.
Sizing the target environment against the real volume with headroom for the conversion's own working space. Import processes need room, and a destination sized only for the data it will hold is a destination that fails part-way through.
Moving the bulk ahead of the window across as many passes as the volume requires, so the cutover handles only the delta. This is the technique that makes a large migration fit a short window, and it is the same at every size — only the number of passes differs.
Converting in segments that record their own progress and can be resumed, so a failure at eighty per cent does not restart from zero. On a large migration this is not a nicety; it is what makes the work completable within a realistic error budget.
Tracking what changed between the bulk transfer and the cutover, and reducing the change rate where possible — by scheduling against the community's quiet period, or by briefly limiting write-heavy activity. The window is a function of the delta, so managing the delta is managing the window.
Per-content-type counting that completes in an acceptable time, with sampling for the structures where a full count is impractical. At this size the reconciliation is a deliverable in its own right and it is built alongside the importer.
The final delta, the switch and the redirect activation as one rehearsed sequence with named owners and a defined rollback trigger. The larger the community, the more the cutover needs to be a procedure rather than a judgement call.
Transfer rate, disk, connection limits and the destination's own write capacity, identified per system. What limits a large migration is usually a specific constraint in one place rather than overall slowness, and naming it is what makes the plan realistic.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
The two numbers that decide everything: how much has to move, and how much of it changes per hour. No method is proposed, and no window is estimated, before both are measured rather than assumed.
The target is provisioned for the data plus the conversion's own requirements plus headroom. A destination that exactly fits the content will fail part-way through, and at this scale that failure is expensive.
The slow part happens in advance, across as many passes as needed. This is the same approach as a small migration, applied repeatedly, and it is what turns an impossible window into a short one.
The conversion records its own progress per segment, so an interruption costs the segment rather than the run. Long processes fail eventually, and the plan assumes that rather than hoping otherwise.
Automated per-type counts, with sampling where a full count is impractical, and an explicit statement of which structures were sampled rather than counted. Claiming exhaustive verification on something that was sampled is worse than stating the sample.
The rehearsal runs against the full dataset, not a subset, because the timing and the failure modes at scale are not visible in a reduced copy. That makes rehearsal expensive, which is why it is planned for rather than improvised.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Schema reverse-engineering and derived-value reconstruction.
Custom forum importersCompatibility positions and staged upgrade paths.
Forum migration to XenForoRedirect mapping at volume and indexation recovery.
Forum SEO migrationCapacity planning and serving-path design for the migrated community.
Server migrationWe will not give a duration before measuring the volume and the change rate, because those two numbers decide it and they vary enormously between communities of similar size. A forum with a very large attachment store and a slow transfer path is a different project from one with the same post count and a fast one. What we will give you after the assessment is the constraint that governs it and a window derived from it.
The window covers the delta rather than the whole dataset, which is what makes a short cutover possible at this size. Its length follows the change rate over the transfer period, so it is managed by reducing the delta — scheduling against the community's quiet period, or briefly limiting write-heavy activity — rather than by transferring faster. We will not promise zero downtime; the cutover is a real event.
The rehearsal has to run at real volume to be meaningful, because the timing and the failure modes at scale are not visible on a reduced copy. If a full-size staging environment is not available, that is a constraint to plan around rather than a step to skip — and the honest options are to provision one temporarily or to accept a longer window with more of the verification happening during cutover.
By counting, not by looking. Reconciliation is automated and structured per content type, and where a full count is impractical we say which structures were sampled rather than counted. What we will not do is present sampling as exhaustive verification, because at this scale the difference between the two is large and the claim would be the thing you relied on.
Running out of something — time, disk, or the destination's write capacity — rather than a conversion error. That is why the constraints are named per system during the assessment, and why the destination is sized with working room rather than only for the data it will hold. A conversion that is correct but does not fit is still a failed migration.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.