The animation pipeline that got you where you are will not necessarily get you where you want to be.
Maybe your renderer is slowing down lookdev iteration. Maybe your rigging framework was built for a single show and has been held together with workarounds ever since. Maybe you have adopted USD on paper but your actual production still runs on a patchwork of custom exporters and format converters that nobody fully understands anymore.
The cost of staying on the current pipeline slowly exceeds the cost of replacing it, and the question becomes how to migrate without burning the production down.
This article answers that question: we'll walk through a phase-by-phase process to pipeline migration in a live production context, from the initial audit to decommissioning. Every section includes actionable insights to give pipeline TDs and VFX supervisors a realistic framework they can actually execute on.
Why You Need a Migration Strategy
Moving to a modern pipeline stack unlocks faster shot iteration, better artist ergonomics, lower licensing costs, and access to a wider talent pool. For example, studios that adopt USD as a common scene description layer reduce the number of custom interchange scripts they maintain, which directly lowers the pipeline engineering overhead per production.
But a pipeline migration isn't a purely technical project. You can't just swap out the tools, update the scripts, and move on. Data loss during asset conversion is the most visible risk, but it's rarely the most damaging one.
A more insidious risk is artist resistance to unfamiliar tools, which can silently destroy throughput without appearing in any bug tracker.
Another one is underestimating legacy dependency depth. For example, a studio migrating from a proprietary shot assembly tool can discover mid-production that their render submission system, their dailies pipeline, and their editorial handoff are all calling internal functions of that tool directly. Replacing it would mean rewriting all three systems at once under deadline pressure.
A migration strategy does not eliminate these risks, but it makes them visible early enough to manage. The same logic applies when migrating production tracking software. At CGWire, we designed our migration strategy for Kitsu around this reality: rather than forcing a sudden cutover, we work with studios to plan the transition so that production keeps moving while the switch happens underneath it.
Phase 1: Audit and Assessment
First, it's important to know exactly what you are migrating with a thorough inventory: every DCC tool in active use, every custom script, every render preset, every submission wrapper, and every pipeline plugin should be documented. Relying on memory or the knowledge of a single senior TD tends to leave gaps. A studio-wide survey cross-referenced against render farm logs will surface tools that are in active use but not officially supported.
With the inventory in hand, documenting how the pieces connect is the next priority. Which tools write to which directories? Which scripts assume a specific version of a DCC? Which asset management integrations break if the folder structure changes? A dependency map is the document that prevents the most expensive surprises. Mapping tools as nodes with a directed edge drawn every time one tool calls, reads from, or writes to another will quickly reveal any node with five or more incoming edges: each of these is a migration risk that deserves its own plan.
This audit phase is also the right moment to review your production tracking setup. Before any tool changes hands, you need a clear picture of your current task structures, project hierarchies, status workflows, and team roles. When studios migrate to Kitsu, CGWire starts here: reviewing the existing setup in detail and translating it into Kitsu without forcing unnecessary changes to how the studio already works.
Not every part of the pipeline deserves equal migration effort. Interviewing department leads to understand where the current pipeline costs the most time helps set the right priorities. A rigging workflow that requires three manual export steps before animation can start is a higher priority than a slightly outdated delivery script that runs once per week. Documenting pain points explicitly ensures the migration addresses the highest-impact areas first.
Rigs, caches, scene files, and shaders all carry implicit assumptions about the software that wrote them. A USD-based pipeline will expect different conventions than a Maya-centric one. Identifying which data formats will survive the migration natively, which ones need conversion scripts, and which ones are essentially unsalvageable and will require manual reconstruction helps shape the scope of Step 3.
Migrating during peak production is also possible but carries a real cost. The ideal window is the transition between productions, or during a pre-production phase when shot pressure is low and artists have bandwidth to learn new tools. When a mid-production migration is unavoidable, a department-by-department approach is far safer than an all-at-once cutover.
The cost of not migrating is real too: every month of delay compounds technical debt. Legacy tools require maintenance, workarounds accumulate, and the gap between the current pipeline and industry-standard practice widens. Factoring that cost explicitly when arguing for migration timing to production is often what makes the case.
Auditing licenses to know exactly which software contracts carry over to the new pipeline, which ones are being dropped, and which ones need renegotiation is a step that pays off early. License costs are frequently underestimated in migration budgets. For studios evaluating production tracking options, Kitsu's open-source model is worth factoring in here: it can be hosted on your own infrastructure, which matters for studios with strict data control requirements or specific client security obligations.
Before anything is changed, establishing performance baselines is key. Depending on your studio's KPIs, measuring render times for representative shot types, iteration cycle time from artist action to rendered result, and asset publish times creates the data needed to prove the new pipeline is an improvement. Specifically, picking three shot archetypes representing easy, medium, and hard production complexity, running them end-to-end, and recording wall-clock time at each stage gives you the success criteria to measure against later.
Phase 2: Planning and Architecture
With a complete picture of the current pipeline state, the target state can be designed intelligently.
"Move to USD" is not a plan. "Adopt USD as the primary scene description format, replace the proprietary renderer with one that ships a native Hydra delegate, and retire the custom asset exchange format in favor of USDZ for final delivery" is a plan. The specificity matters because vague goals cannot be tracked, cannot be communicated to artists, and cannot be used to evaluate whether the migration is complete. Naming the specific tools, frameworks, and workflows that constitute the new stack along with key evaluation metrics make a plan actionable.
A migration roadmap should identify what gets migrated in which order, what the validation criteria are for each phase, and what the rollback procedure is if a phase fails. For example: Phase 1 covers the asset pipeline only (no shots), validated by a visual diff review of ten hero assets. Phase 2 covers lighting and lookdev for a single department, validated by a full shot render comparison. A useful fallback for Phase 2 would be keeping the old pipeline available for that department for four weeks post-cutover.
A parallel-run strategy keeps both pipelines active simultaneously, letting artists migrate gradually while the old pipeline remains available. A hard-cutover shuts down the old pipeline on a set date and moves everyone to the new one. Parallel-run is lower risk but more expensive to maintain and can allow migration to stall indefinitely without an enforced cutover date. Hard-cutover is faster but requires high confidence in the new pipeline and a strong support plan for the transition period. With Kitsu, we go for the parallel-run approach first: studios can run it alongside their existing production tracker, compare task data, progress reports, and artist assignments side by side, and only commit fully once everything matches expectations.
It's worth asking early: can assets created in the old pipeline load in the new one? If yes, in what form? Read-only for reference, or fully editable? Backward compatibility is not always achievable, but the scope of what is and is not compatible should be documented explicitly so that artists know what to expect. A studio that discovers mid-production that its new pipeline cannot load legacy cache files will lose significant time rebuilding assets that should have been handled during planning.
The same principle applies to production data: projects, shot lists, task assignments, and production notes represent months of decisions and communication. Kitsu allows structured import of this data through CSV or HTTP API, covering projects, sequences, episodes, assets, shots, task structures, status workflows, and comments, so that studio history is not abandoned when the tool changes.
Not all assets are equally complex to migrate. A simple prop with a straightforward shader is a low-risk migration. A hero character with a custom muscle simulation, a proprietary hair solver, and baked-in poses from a previous show is a high-risk migration. Assigning each major asset class a risk tier and sequencing the migration accordingly with low-risk assets first to build confidence and surface process issues early, high-risk assets later with lessons learned, is a reliable way to manage exposure.
Again, declaring in writing what "migration complete" means before the work starts, is one of the most valuable things a team can do. Concrete metrics worth considering include: render time delta versus baseline (target: no regression, ideally improvement), iteration cycle time (target: measurable reduction from baseline), zero active use of legacy tools in production, and all assets publishing and loading cleanly in the new system. Without agreed-upon success criteria, migration projects can drag on indefinitely because there is no objective way to close them.
Phase 3: Data and Asset Conversion
The difference between a migration that succeeds and one that creates months of rework lies in the quality of the conversion layer.
Every major data type in the pipeline needs a scripted conversion path: scene files, rig exports, shader assignments, simulation caches, etc. Manual conversion at scale is not feasible and introduces inconsistency. For example, when migrating shaders from a proprietary format to another, a conversion script that maps each legacy material type to its equivalent, handles edge cases explicitly, and logs every asset it processes with a pass or fail status will save significant time while reducing errors.
Asset conversion makes naming and structure decisions irreversible at scale. Converting ten thousand assets and then discovering a flaw in the naming convention means a second pass through the entire library, so finalize and document conventions first then convert, to avoid that scenario.
Before running the full library, it's advisable to run pilot conversions on a small set of assets that represents the breadth of production complexity: a simple prop, a medium-complexity character, a complex environment with multiple sub-assets, and an edge case that is likely to cause problems, for example. Careful review of these pilot outputs pays for itself many times over: issues found on ten pilot assets are cheap to fix.
Visual diffs are the minimum validation standard. For rigs, it's important to validate deformation behavior, control range, and skinning quality across a standard pose set. For shaders, validating appearance under multiple lighting conditions (not just a neutral gray dome) is key. For caches, verify that timing, scale, and world-space position are preserved. Defining a sign-off checklist for each asset type and requiring a reviewer to approve each converted asset before it enters the new pipeline ensures quality throughout.
Phase 4: Tool and Software Integration
Converting assets is only half the work: the tools that create, publish, and consume those assets all need to function in the new environment.
For each custom pipeline plugin, the team will need to make an explicit decision: port it to the new environment, rewrite it from scratch, or replace it with a native feature of the new software. Porting preserves behavior but can carry over technical debt. Rewriting is slower but produces cleaner code. Replacement is fastest when the new tool genuinely covers the use case. The migration is a good opportunity to retire plugins that were workarounds for problems the new pipeline no longer has, rather than defaulting to porting everything out of habit.
The asset management integration is the connective tissue of the pipeline. It controls what artists can load, what they can publish, and how work moves between departments. This integration should be built and validated before artist rollout, not after. Testing the full publish-checkout-iterate loop for every department workflow in a staging environment, before any artist touches it, is the safest approach. Kitsu is designed to fit into existing pipelines: its REST API and Python client allow technical teams to connect it to DCC tools for publishing previews directly, to render farm systems for tracking outputs, and to asset management systems already in use without forcing a pipeline rebuild to accommodate the tracker.
A new renderer means a new submission tool and new farm configuration. It's important to test render farm behavior under load, not just for single frames, since render farm issues under production load are common and often cannot be reproduced with a handful of test frames. Running a farm stress test using a representative batch of shots before declaring the render pipeline production-ready is strongly advisable.
Lastly, when the new pipeline changes how assets are versioned, named, or stored, the publish and checkout tools need to reflect that precisely. Any mismatch between tool behavior and the actual file system state leads to broken references, lost work, or silent overwrites.
Phase 5: Testing and Validation
Testing is where assumptions meet reality.
A shot is not just assets and renders: it's the full chain from scene assembly through lighting, FX, compositing, and delivery. Running representative shots through every stage of that chain and confirming that the output at each step matches expectations is essential. Any breakage in the chain that is not caught in testing will be caught in production at the worst possible time.
Rendering the same shots through both new and old pipelines and doing a side-by-side comparison is a reliable way to characterize the differences. Those differences should be documented and classified: expected differences due to renderer changes, unexpected differences that indicate conversion errors, and acceptable differences that have been reviewed and signed off. The goal is not identical output but understood output.
Measuring render times, iteration cycle times, and publish times on the same shot archetypes measured at the start is important at this stage. If the new pipeline is slower, understanding why before rollout is essential. A migration that improves capability but degrades performance will face strong artist resistance.
Complex simulations, crowd scenes, shots with many layers of nested references, and shots that push the limits of the rig or the renderer are the cases most likely to break under load. These deserve prioritized testing attention.
When the new pipeline changes how the asset management system or the file server is structured, access control needs explicit validation. It is common for migrations to inadvertently broaden file permissions or break department-level access controls. An artist who can accidentally overwrite another department's published assets is a production risk, so running a permissions audit beforehand is a worthwhile precaution. For studios using Kitsu, this is also the point to validate that role-based views are configured correctly, i.e that artists see their task queues, supervisors see their review queues, and producers see schedules and budget data, with no unintended crossover.
Phase 6: Artist Training and Rollout
A technically correct migration that artists do not trust or adopt is a failed migration.
Department heads, producers, and VFX supervisors should understand the migration rationale, the timeline, and what they are being asked to do before their artists hear about it. Surprises erode trust: a studio that announces a pipeline migration to artists before the heads of department have been briefed will spend weeks managing confusion and resistance that could have been avoided.
Reference documentation describing every tool in the new pipeline is useful. Step-by-step tutorials covering the ten most common daily workflows are more useful. Writing documentation from the perspective of the task, rather than the tool, serves artists better. "How to publish a rig" is a better document title than "RigPublishTool API Reference" for an artist audience.
Modeling, rigging, animation, FX, and lighting all have different workflows and different concerns. A single all-hands demo is rarely sufficient. Separate sessions for each department, focused on the workflows that department performs daily, tend to land much better. Hands-on practice during training, with a real asset and real tools, is significantly more effective than watching a demo. Kitsu's onboarding approach is built around this same principle: supervisors are trained first so they can guide their teams, and artist training focuses specifically on the task views and update workflows each role uses every day, rather than a generic platform walkthrough.
A champion is a senior artist or TD in each discipline who has been trained ahead of the general rollout, understands the new pipeline deeply, and is available to support their peers during the transition. Champions are more accessible than pipeline TDs, speak the language of their department, and can resolve a large proportion of day-to-day questions without escalation. Finding and investing in champions is one of the highest-leverage actions in a migration rollout.
The most reliable rollout sequence is: pilot team first, then one department, then the full studio. The pilot team surfaces workflow issues that testing did not catch, allows the training materials to be refined, and produces early success stories that reduce resistance in subsequent rollouts. Pressure to do a full-studio cutover on day one is worth resisting because the risk is usually not justified by the time savings.
Phase 7: Parallel Production and Stabilization
The transition window between old and new pipelines is the highest-risk period of the migration.
During the transition window, shots may be in-flight on either the old or the new pipeline. Both need to be functional, monitored, and supported. This costs pipeline engineering bandwidth, but the alternative is being unable to deliver shots that are mid-production when the cutover happens.
Shots that are in final delivery on the old pipeline should not be migrated mid-stream. Designating a set of pipeline engineers responsible for supporting the legacy pipeline during the transition window, and defining clearly when that support ends, helps avoid ambiguity and keeps both sides of the transition properly staffed. For production tracking specifically, this parallel window is where Kitsu's side-by-side approach pays off: producers can run progress reports and compare task data between both systems before committing fully, which provides the confidence to set a real cutover date rather than letting the transition drag on indefinitely.
Migration-related issues are best tracked separately from normal production support, to keep patterns visible. If five different artists report the same publish failure in the same week, it's a systemic issue, not five individual bugs.
During the transition window, the pipeline should change as little as possible because new features introduce new failure modes at a time when the team is already managing elevated risk. A feature freeze policy with exceptions for production-critical fixes only is the right approach during this period.
Phase 8: Decommissioning and Documentation
The migration is not complete until the old pipeline is retired and the new one is thoroughly documented.
Rather than deleting the old pipeline, archiving it in a state where it could be accessed if a historical asset needs to be recovered is the safer long-term approach. You can label everything with the version and the date of decommission. Assets delivered on a prior show may need to be rebuilt years later, so the storage cost is worth it. Because Kitsu is open source and can be hosted on your own infrastructure, your production data remains accessible and auditable long after a show closes. There is no vendor lock-in that could strand historical records.
The pipeline that exists only in the heads of three senior TDs is a business continuity risk. Documenting the architecture of the new pipeline (how assets move through it, what each tool does, what the dependencies are, and where the configuration lives) is the foundation for onboarding future pipeline engineers and for planning the next migration.
Running a formal post-mortem is also valuable: What worked? What did not? Where did the timeline slip and why? What would be done differently? A post-mortem is a structured process for capturing institutional knowledge before the team moves on to the next production. The findings should be written down and made available to whoever plans the next migration.
The most common reason studios find themselves doing emergency migrations rather than planned ones is that the pipeline drifted without governance. Putting a lightweight change management process in place, where any significant change to the pipeline goes through a review, is version-controlled, and is documented, prevents that drift.
Conclusion
The eight steps we listed are not a guarantee against problems. Migrations are complex, productions are unpredictable, and legacy systems have a way of surprising you. But what a structured approach does is shift the nature of the problems encountered from catastrophic surprises that stop production to manageable issues found and fixed in the right order.
The most important principles hold throughout: auditing before planning, planning before building, building before training, and training before cutting over. Defining success explicitly and measuring against it. Treating artist adoption as equal in importance to technical correctness. Running in parallel during the transition and enforcing a hard decommission date.
A pipeline migration is not a one-time event. Studios that build the discipline to migrate cleanly develop a structural advantage over those that do not: they adopt new tools faster, carry less technical debt, and are able to attract engineers who want to work in a well-maintained system.
The process described here is how you build a studio that is not held hostage by its own infrastructure.
With Kitsu, your team can be tracking tasks, reviewing assets, and logging time within hours of signing up. Studios across 50+ countries from small agencies to large VFX houses have made this switch without pausing a live production.
