Burning Sapp

Service 03

Compliance-Grade Migration

Some migrations finish when the code works. Others finish when someone outside your team can be shown, on paper, that nothing changed except what was supposed to. We work to the second standard, and we build the evidence as we go rather than reconstructing it afterward.

A diff: undocumented process removed, traceable evidence added.
- tribal knowledge, verbal sign-off
- "it behaves the same, trust us"
+ traceable change record
+ test-parity evidence, signed

01 · Definition

What compliance-grade means here.

It is not a certificate and it is not a stamp. It means the work is done so that four questions can be answered about any line that changed, at any point, months later, by someone who was not there.

  • Why did this change? Traceable back to a requirement, defect, or approved decision.
  • Who approved it, and were they entitled to? Recorded at the time, not reconstructed later.
  • How do we know it did not break anything? Test evidence produced before and after, kept.
  • What was the state of the system on any given date? Reconstructable from the record.

02 · Artifacts

What lands on your side.

These are deliverables with due dates, reviewed the same way the code is. The point of writing them during the work is that they describe what happened rather than what somebody remembered afterward.

Record

Change record

Every change, with its reason, its approval, its test result, and its date. Formatted to drop into your existing change management system rather than sit beside it.

Trace

Traceability matrix

Requirement to design decision to commit to test case to result. The document an auditor asks for on day one and that most projects assemble in a panic on day three.

Proof

Test-parity evidence

Old system and new system, same inputs, recorded outputs, differences explained and signed off individually. This is the core of the argument that nothing changed.

Summary

Validation summary

What was tested, what was not, what the residual risks are, and who accepted them. Written to be read by someone senior who has fifteen minutes.

Operate

Runbook

How to run, monitor, restart, and roll back the new system, written for the person on call at 3am who has never seen it before.

Handover

Handover pack

Architecture as it now is, decisions and why they were made, known issues, and the things we would do next. Done means documented.

03 · Fit

We work inside your process, not beside it.

You already have a change board, a ticketing system, an approval chain, and a set of controls somebody spent years getting signed off. We are not going to ask you to run a second process for our convenience.

Change control
We raise changes through your system, in your format, to your board's calendar.
Access
Least privilege, named accounts, and whatever screening or background checks your policy requires before we start.
Separation
Where your controls require that the person who writes a change is not the person who approves or deploys it, we structure the work that way and the record shows it.
Environments
We work in the environments you designate. Production access is on your terms or not at all.
Frameworks
The evidence is built to slot into the control framework you already report against, whether that is SOX, HIPAA, PCI DSS, FDA 21 CFR Part 11, or an internal standard.
Confidentiality
NDA before the first code review. We do not name clients publicly without written permission.

04 · Limits

What we are not.

Read this part twice

We are engineers who produce evidence. We are not your auditor, your qualified person, your regulatory affairs function, or your QA department of record, and we cannot certify our own work on your behalf. Anyone who tells you otherwise is selling you a problem.

What we do is make your compliance people's job straightforward. They define what evidence is required. We produce it during the work, in the format they ask for, and we are available to answer questions about it during an audit. The sign-off stays with the people whose job it is.

05 · Questions

What people ask before hiring us.

How much does the documentation add to the cost?

Less than you would expect, because most of it is a byproduct of working carefully rather than an extra task at the end. The parity evidence exists anyway, since we run old and new side by side on every migration. Writing it up properly is the additional effort, and it is usually in the range of ten to fifteen percent.

Our auditors have specific templates. Will you use them?

Yes, and please send them at the start rather than at the end. Producing evidence in your format from day one costs nothing. Converting it afterward costs real money and introduces transcription errors into exactly the document that should not have any.

Can you work in an air-gapped or restricted environment?

Yes. Tell us the constraints before the assessment so we can price the work honestly, because restricted environments genuinely slow things down and we would rather say so up front than discover it in month two.

What happens if we get audited mid-project?

You hand over the change record and the traceability matrix as they stand. They are current, because they are written as the work happens. That is the entire reason for doing it this way.

Do you carry insurance?

We bind it per engagement rather than carrying idle policies. Send your insurance requirements with the contract and you will have certificates in hand before the first day of work, including additional insured naming where your paper calls for it.

Contact

Tell us what you have to prove, and to whom.

Your framework, your auditor's expectations, and the system in question.