Our own tracker, moved off .NET Framework and proven page by page.

1 · The system

What the tracker is

Clients open topics (bugs, requests, questions) in their projects; the team replies, assigns, estimates, plans its days and tracks time against each topic. Managers see the work by person, project and status. The tracker has grown over many years, and the inventory found more than the team uses today.

3 · Slice 1

Time tracking: record first, then rewrite

The timer is small, but its rules decide how much time is recorded: how a stop is rounded, what happens at midnight, which day a long run counts on. It was the first slice because it can be pinned down exactly.

1. Run the old site on a machine of its own

   A script creates a temporary Windows Server 2022 machine with SQL Server 2022 Express in our own AWS account, with no inbound access. It builds an empty copy of the database from the schema, adds test projects and topics, and installs the old site in IIS, unchanged apart from its configuration. No client data goes to this machine.

2. Set the clock for every step

   For each of 20 cases, the harness sets the machine's clock, calls the old timer the way the browser does, and saves the response and every time-entry row after it. That is how midnight, daylight-saving changes and a 15-hour run can be tested in minutes. The machine is deleted after the run.

3. Replay on the new code

   The new timer runs each case with the clock set to the moment the old one saw, first in memory, then on PostgreSQL. 71 steps and 102 row comparisons, ten fields each: no differences.

4. Report what the recording showed

   • Every stop rounds up to the next minute, milliseconds included, so a stop almost always adds a minute: an 80-minute run is stored as 81 minutes, and ten 30-second runs as 10 minutes.
   • Daylight saving is counted in clock time: 4 real hours across the November change are stored as 3, and 1 real hour across the March change as 2.
   • A topic name with an apostrophe can never be stopped: the name is saved with a different character, so the timer never finds itself running.
   • The timer had access gaps: some calls did not check who was asking or whether they were on the project.

   Each of these is now an approved change with its own test, and the new timer can still run in a legacy mode that reproduces the old behavior exactly. Kept on purpose: the 15-hour cap applies only when starting one timer stops another, and time past midnight stays on the day the timer started.

5 · Slices 3 and 4, writing

Proving what gets saved and who gets mail

For every action that changes data, the question is not only what the page shows next, but which rows change in which tables, and which e-mails go to whom.

1. Record each action on the test database

   Each case signs in as a test user, sets the clock and performs the action through the old pages: add a topic, reply, reassign, hide a post, edit, plan a day, move an epic. After each step the harness saves the rows of twelve tables and every mail the old site wrote, with mail delivery pointed at a local folder.

2. Replay and compare

   Area	Cases	Result
   Topics: add, reply, status, take it, hide, subscribe, edit, priority order, description, access refused	18	Same, with the approved changes
   Planning: plan dialog, move a day, topic panel, copy, close on the board, epics, sprints	12	Same
   Editing a sprint's date	1	Deferred: the capture script could not drive that grid; unit tests cover it

3. Report what the tests found

   • Saving the edit page wiped the topic's description, because the page never loaded it into its form.
   • The edit page failed with an error on topics without a completion date.
   • Internal replies were e-mailed to clients like any other reply.
   • Every notification went out as one mail with all recipients in the To line, so clients saw each other's addresses.
   • Mail subjects arrived encoded, with + for every space.
   • "Take this topic" was in the page but never shown.
   • The progress log was never written: its SQL had a stray bracket, so it always failed.
   • Several actions checked access weakly or not at all, and some changed data from a plain link.

   Some of the old behavior was matched on purpose, because people rely on it: a client's reply sends the topic back to the last person it was assigned to, and a topic created from the plan dialog is due today.

7 · Data and the server

Moving the data and running it

1. Same tables, a new database

   The schema is converted table by table, keeping every column the old site wrote, so new topics look exactly like old ones. Text that SQL Server compared without case is compared without case in PostgreSQL too; name-based links between tables depend on it.

2. A migration tool that checks itself

   One command copies the data, another compares every table with the source by row count and checksums and writes a report. Users keep their passwords: the old encrypted passwords are decrypted once with the old site's key and stored with a modern hash; the old key is destroyed after the switch.

3. A small server that is easy to rebuild

   One Amazon Lightsail instance runs the app, PostgreSQL and Caddy for HTTPS. The database is backed up every night to Amazon S3 and kept 35 days; the whole server is snapshotted daily; attachments are versioned. A release is a zip uploaded by one script, with about five seconds of downtime and a rollback in seconds. Everything is created from one AWS CloudFormation template.

4. A rehearsal before the switch

   The switch is written down step by step, with the way back. Before it happens, the full migration runs once on a copy of the real data, the comparison report must come back clean, a backup must restore, and the team tests the new tracker on its own work.