For engineers
For data engineers: what automation takes off your desk, and what stays yours
Novuz converts the logic by fixed rules, and the engineers who know the estate decide what ships. The rewriting goes; the judgment stays with the team. Here is what that means day to day.
What goes
What comes off your desk
- Rewriting procedures, packages and scripts by hand, object by object.
- Rebuilding schedules from memory; they are rebuilt with their original dependencies.
- Building test harnesses for every object; each gets a reconciliation report on the same inputs.
- Re-fixing the same pattern in a thousand places; a fix is a rule change applied everywhere the pattern occurs.
What stays
What stays yours
- Approving or rejecting every resolver proposal, for the roughly 5% of objects rules do not cover. Nothing deploys unapproved.
- Reviewing Script Task and Script Component code, and any object marked review.
- Setting the coding and naming standards the conversion follows, and the output language: SQL, PySpark or both.
- Confirming the dead-code list, and adding the business checks you already trust to the reconciliation.
- Owning the converted code afterwards: it is native to your platform, with no Novuz runtime.
Standards
Will the output meet our standards?
Give us your standards before the First Domain, and the rules apply them across the estate. The code is readable and native to your platform, so run it through your own linters and style checks in the First Domain review, before the rest of the estate moves.
Reviewers
Who reviews the output, and how do they learn?
A named engineer from your team approves resolver proposals; each proposal comes with its reason, and every decision is logged. In the First Domain, a Novuz engineer works beside your team, so the people who will own the code learn the review on your own objects.
Buy-in
How do we get the team on board?
Let the team test it. Pick the ten objects they trust least, convert them twice, and diff the outputs. Then read the reconciliation reports together. Engineers are rightly skeptical of conversion demos; an empty diff on their own code answers most of it.
Next question
Where to read next
Which patterns break in conversion, by dialect?
FAQ
Frequently asked questions
Will migration automation replace our data engineers?
No. Rules do the rewriting; engineers approve every resolver proposal, review flagged objects, set the standards the output follows and own the converted code. The work moves from rewriting to reviewing and deciding.
What stays manual in an automated warehouse migration?
The objects rules do not cover, about 5%, which go to a resolver and need an engineer’s approval; Script Task code; and any object marked review. Under our counting rule, a one-line fix counts as manual.
Does converted code follow our coding standards?
Yes, if you give them before the First Domain: the rules apply them across the estate. Review a sample against them, and run your own linters, before the remaining domains convert.
How do we get engineers to trust a conversion tool?
Let them test it on the objects they trust least: convert each twice, diff the outputs, and read the reconciliation reports together.
Last reviewed:
Find out what your logic debt is costing you.
Every object counted, lineage, dead code and a fixed price in three business days. $3,000, credited.
Not sure which door? The scorecard takes ten minutes and tells you.