Scheduling Data Migration

Why Moving Schedule Data Is Harder Than It Looks

Switching scheduling systems sounds like an IT problem. It isn't. It's a jobsite problem wearing an IT costume. When you move your schedule data from one platform to another — off a spreadsheet, off an old desktop tool, or from one cloud app to the next — you're not just copying rows. You're carrying over the logic that tells your crews where to be next week, the trade-flow sequences your subs have already agreed to, and the history that lets you argue a delay claim eighteen months from now. Break any of that in transit and the schedule stops being trustworthy. And a schedule nobody trusts is just a wall decoration.

I've watched a migration go sideways on a live multi-family job. The old system got shut off on a Friday, the new one was supposed to be ready Monday, and half the activity relationships didn't survive the export. By Tuesday the framing crew was standing around because their look-ahead showed them a location that MEP hadn't even reached yet. That's a two-day hole you can't get back, and it started with a data problem nobody tested. This article is about not being that job.

Start With an Honest Data Assessment

Before you touch a single export button, take inventory of what you actually have. Most schedule datasets are messier than their owners admit. You'll find duplicate activities, orphaned tasks with no successor, crews assigned to work that finished last spring, and location names that three different people spelled three different ways.

Walk through and sort your data into three buckets:

• Move it. Active projects, current look-aheads, live trade-flow sequences, crews and companies still on the job, and any historical schedule you might need for a claim or a lessons-learned review.
• Archive it, don't migrate it. Closed-out jobs from years ago. Export those to PDF and flat files, drop them on a server, and leave them out of the live system. Dragging a decade of dead projects into a new platform just slows every screen down and buries the data you actually use.
• Kill it. Test schedules, duplicates, the "Copy of Copy of Final" versions. Migration is the one honest chance you'll get to clean house. Take it.

Do this cleanup before the move, not after. Garbage that survives migration is twice as expensive to fix once it's living in the new system and tangled into new relationships.

Map the Fields Before You Move Anything

This is where most migrations quietly break. Two systems almost never store the same concept the same way. Your old tool might call it "Area," the new one calls it "Location." One stores durations in days, the other in working hours. Dates might be MM/DD/YYYY on one side and ISO on the other, and if your export doesn't declare which, you'll silently swap months and days on every date past the twelfth — the kind of error that looks fine until March 4th shows up as April 3rd.

Build a field map on paper — a simple table with the old field, the new field, and any conversion rule — before anyone runs anything. Pay special attention to the things that carry meaning beyond a single cell:

• Relationships and dependencies. Finish-to-start, start-to-start, lags and leads. These are the whole point of a schedule. If a migration flattens your activities into a list and drops the links between them, you don't have a schedule anymore — you have a to-do list. Confirm the new system's import can carry predecessor/successor logic, and check a sample by hand.
• Location and trade-flow structure. Location-based schedules live or die on their geography. If your zones, floors, or units don't map cleanly, your trade flows won't sequence right. In LookAheadWall, for instance, the work is organized by location and connected through trade-flow lines, so the location hierarchy has to come across intact or the flows have nothing to attach to.
• Calendars and non-work days. Holidays, weather days, and shift calendars change the math on every date. Migrate the calendar, or your imported finish dates will drift.
• Crews, companies, and assignments. The link between a task and who's doing it is easy to lose because it's often stored separately. Verify assignments came through, not just the tasks.

Always Migrate a Sample First

Never do a full migration cold. Pull one representative project — ideally a mid-sized active job with real trade flows, multiple crews, and a full calendar — and run it through the whole process end to end. Then sit down and compare it to the original, field by field, on the parts that matter.

A good validation pass answers concrete questions, not vague ones:

• Do the activity counts match? If you exported 1,240 activities and imported 1,205, thirty-five things vanished. Find them before you trust anything.
• Do the start and finish dates line up on a spot-check of ten or fifteen activities across different weeks? A single-cell date-format bug shows up here.
• Did the dependencies survive? Pick a chain — say, layout to frame to rough-in to inspection to close-in — and confirm the links are still there and pointing the right direction.
• Are the durations the same after any units conversion? Ten working days should still be ten working days, not fourteen calendar days.
• Did the look-ahead still resolve correctly? Generate next week's work plan in the new system and see if it shows the same crews in the same locations the old one did.

The sample migration is cheap insurance. It's a couple of hours that saves you a couple of weeks. Do it every single time, even when the vendor swears the import is bulletproof.

Plan for the Errors You Know Are Coming

Some data will not convert cleanly. Count on it. A field that's blank in the old system but required in the new one, a duration of zero, a crew that was deleted but is still referenced by an old task — these throw errors, and you want a plan for them before they show up, not a panic.

Keep an exception log during the test run. For each error, decide the rule now: default the blank field to a sensible value, drop the orphaned reference, or flag the record for a human to fix by hand. Then apply the same rules on the real run so the results are predictable. The worst migrations are the ones where someone made a hundred snap judgments at 11 p.m. and can't reconstruct a single one the next morning.

Cutover: Pick the Right Moment and Protect It

The cutover — the moment the old system goes dark and the new one goes live — is the single riskiest hour of the whole job. Treat it that way.

A few hard-won rules:

• Cut over on a slow window, not a Friday afternoon. A long weekend or a scheduled shutdown gives you room to fix problems before crews depend on the output. Cutting over the night before a big pour is asking for it.
• Freeze the old data during the move. If people keep editing the old schedule while you're migrating, your new system launches already out of date. Lock it, do the move, then open the new one.
• Keep the old system readable, not just gone. Don't cancel the old license the day you flip the switch. Keep it in read-only reach for a few weeks so you can settle "the new one says X, what did the old one say?" arguments with a fact instead of a guess.
• Have a written rollback plan. If the new system is a mess by Monday morning, exactly how do you get back to the old one, and what's the point of no return? Write it down before cutover. Rollback you didn't plan for at 6 a.m. isn't a plan, it's a prayer.

The People Side: Training and Timing

Clean data means nothing if your superintendents and foremen can't find their week in the new tool. Line up training so it lands right when the migrated data goes live — not two weeks early when there's nothing to practice on, and not two weeks late when everyone's already invented their own workarounds.

Focus the training on the handful of things a crew leader actually does: pull up this week's work plan, see where their trade is going next, spot the hand-off from the crew ahead of them. If the mobile companion app is part of the rollout, get crew leaders logged in and looking at real, migrated data on day one. People trust a tool they've already used to find their own name on a real schedule.

Document It While It's Fresh

The day after a successful migration, write down what you did — what moved, what got archived, what field mapping you used, and every judgment call you made on the exceptions. It feels like busywork. It isn't. Six months later when someone asks why the 2023 jobs aren't in the system, or why a duration looks off, that one page is the difference between a two-minute answer and a two-day investigation. It's also your template for the next migration, because there's always a next one.

The Short Version

Schedule data migration goes well when you treat it like a phased jobsite task instead of a copy-paste: assess and clean first, map the fields on paper, test with a real sample, validate the counts and the relationships, plan for the errors, cut over on a slow window with a rollback ready, train people on live data, and document the whole thing. Skip the sample run to save an afternoon and you'll pay for it with a week of chasing missing dependencies while your crews stand around. The goal isn't just to move the data — it's to come out the other side with a schedule your subs still believe. Get that right and the new system starts earning its keep the first Monday it's live.