How to Migrate From Stable Diffusion to Flux
Stable Diffusion users who've been running local workflows for a year or two tend to have intricate setups: custom checkpoints, a library of LoRAs, ControlNet pipelines for pose and depth conditioning, and carefully tuned CFG and sampler configs. That investment is real, and it's the main reason people hesitate when they hear about Flux.
The reason they make the move anyway is usually image quality. Flux.1 Dev and Flux.1 Pro produce significantly better anatomical accuracy, cleaner text rendering, and more coherent complex scenes than SDXL or SD 1.5. The underlying architecture, a diffusion transformer instead of a U-Net, handles spatial relationships in ways the older models can't. For many workflows, the quality jump is large enough to justify rebuilding pipelines.
That said, this isn't a drop-in upgrade. Sampler settings don't transfer. CFG scale works differently. And while Flux ControlNet support exists, the specific nodes and model files differ from what you've been using with SDXL.
What's actually different
Stable Diffusion (particularly SDXL) uses a U-Net architecture with cross-attention for text conditioning. Flux.1 is a diffusion transformer (DiT) with a multimodal approach, the text conditioning and image generation are handled by the same transformer blocks rather than separately. This is why Flux handles text within images so much better: the model doesn't treat the visual and linguistic parts as separate problems.
| Dimension | SDXL | Flux.1 Dev/Schnell |
|---|---|---|
| Architecture | U-Net | Diffusion Transformer |
| CFG scale | 5-12 typical | 1-3.5 range; guidance differs |
| Sampler | DPM++ 2M, Euler, etc. | Euler/DDPM-style; fewer options |
| ControlNet | Extensive ecosystem | Available, fewer variants |
| LoRA | Broad library | Growing; separate training method |
| VAE | Separate component | Integrated (uses SDXL VAE) |
| Text rendering | Poor | Strong |
| VRAM (base) | 6-8 GB | 24 GB for Dev; 12 GB quantized |
| Prompt style | Keyword stacking + weights | Natural language |
The VRAM jump is significant. Flux.1 Dev in fp16 requires around 24 GB. The community has released fp8 and NF4 quantized versions that run in 12-16 GB, with some quality trade-off. If you're on a 12 GB card, plan for quantized runs.
Mapping your existing prompts and settings
CFG scale. In SDXL you probably run CFG between 6 and 9. In Flux.1 Dev, the effective guidance range is much lower, typically 1.0 to 4.0. Start at 3.5 and go lower if outputs look oversaturated or overprocessed. Flux uses a different guidance mechanism (guidance distillation in the Schnell version), and the old intuition about "higher CFG = more prompt adherence" doesn't apply the same way.
Samplers. Your DPM++ 2M Karras workflow doesn't map directly. Flux in ComfyUI typically uses the euler sampler with the FluxGuidance node for proper guidance conditioning. The specific ComfyUI Flux workflow files from the community (search "ComfyUI Flux workflow JSON") wire this correctly, don't try to use an SDXL workflow and swap the checkpoint.
ControlNet. Flux ControlNet support is handled through a separate set of model files. The Flux Canny and Depth ControlNet models from Jasper (the XLabs-AI release) are the most used. They're not the same files as your SDXL ControlNet models. Download them from Hugging Face (jasperai/Flux.1-dev-Controlnet-Canny and jasperai/Flux.1-dev-Controlnet-Depth) and wire them into the Flux ControlNet ComfyUI node, not the standard ControlNet node.
LoRAs. SD and SDXL LoRA weights are not compatible with Flux. Flux LoRAs require retraining on the Flux model. If you've been using downloaded LoRAs, check Hugging Face and Civitai for Flux-compatible versions of the same concepts. For custom LoRAs you trained yourself, you'll need to re-run the training process using Flux LoRA training scripts (Kohya-ss supports Flux as of its recent releases).
Prompt style. SD/SDXL prompting rewarded dense keyword lists: beautiful woman, detailed face, (masterpiece:1.3), (photorealistic:1.2), studio lighting, bokeh, 8k. Flux is trained on natural language and performs worse with keyword stacking and attention weighting syntax. Write a professional headshot of a woman with detailed features, studio lighting, shallow depth of field, sharp focus, 8K resolution instead. Drop the parenthetical weights entirely, Flux ignores them.
Negative prompts. SD relied heavily on long negative prompts to prevent artifacts. In Flux, negative prompts have less effect because the architecture handles this differently. A short, targeted negative prompt (blurry, deformed hands, watermark, low quality) is more effective than a 100-word SD-style negative block.
The actual migration steps
1. Set up the Flux workflow in ComfyUI. Install the latest ComfyUI and download the official Flux workflow JSON files from the ComfyUI GitHub or the community hub. The Flux workflow requires different custom nodes than standard SDXL, specifically the ComfyUI-Flux or ComfyUI_bfl_api node packs depending on whether you're running local or API.
2. Download the model files. For Flux.1 Dev: download the model from Hugging Face (black-forest-labs/FLUX.1-dev). You need a HuggingFace account with access approved. Place the .safetensors file in your ComfyUI models/unet directory. Also download the T5-XXL text encoder and CLIP-L encoder to models/text_encoders, and the SDXL VAE to models/vae.
3. Run a baseline test. Before attempting to port your existing workflows, run the stock Flux Dev workflow on a straightforward prompt. This confirms your setup is working and gives you a quality baseline.
4. Rebuild your ControlNet pipelines. Download the XLabs Flux ControlNet checkpoints for the conditioning types you use. Wire them into the Flux-specific ControlNet nodes in ComfyUI. Your old ControlNet preprocessors (Canny edge, depth map, DWPose for pose) still work as preprocessors, the output maps are the same format. Only the actual ControlNet model files and the conditioning node change.
5. Port your LoRAs. Check Civitai and Hugging Face for Flux-native versions. For anything you trained yourself, use Kohya-ss with Flux LoRA training mode. Expect training times to be longer than SDXL LoRA training on equivalent hardware.
6. Rebuild your prompt templates. Take your best 20 outputs from SD/SDXL and use them as reference images. For each, write a natural-language Flux prompt that describes what you see in the image. This is more useful than trying to translate the original keyword-stacked prompts.
Gotchas you'll hit
VRAM pressure. Even with fp8 quantization, Flux is heavier than SDXL. If you're running other applications alongside your generation workflow, expect OOM errors until you clear resources. The quantized versions at NF4 precision can run in 10-12 GB but produce noticeably softer outputs.
Workflow files break constantly. ComfyUI's Flux support has been evolving fast. A workflow JSON that worked three months ago may throw node errors after updates. Keep a backup of working workflow states and update node packs incrementally, not all at once.
Slower iteration. Flux.1 Dev on a 24 GB card generates a 1024x1024 image in 20-40 seconds depending on step count. SDXL on the same card at 20 steps is faster. Flux.1 Schnell is significantly faster (4-8 steps for usable quality) but was designed for speed over fidelity.
Text encoder requirements. Flux requires the T5-XXL encoder, which is 10 GB. If you're tight on disk space this is a real consideration. Some quantized T5 versions exist, with modest quality trade-offs.
The artistic aesthetic is different. SD/SDXL with the right checkpoint produces a painterly, illustrative look that many creative workflows depend on. Flux defaults to photorealism. If you've been running an anime or illustration checkpoint, there's no direct equivalent in Flux yet, the Flux LoRA ecosystem is catching up but isn't at SDXL's breadth.
When NOT to switch
If your entire workflow is built around a fine-tuned SDXL checkpoint that produces a very specific look, say, a trained model for architectural visualization or anime that has years of LoRA refinement, staying on SDXL makes sense until equivalent Flux fine-tunes exist.
For 12 GB or less VRAM without willingness to use quantized models, SDXL is still the more practical option. The quality-to-VRAM ratio on SD 1.5 and SDXL is better at that memory level.
If you're deep in img2img workflows with inpainting masks and the SD inpainting ecosystem, note that Flux Fill (the inpainting variant) has less community tooling than SD inpainting currently.
Switch to Flux when output quality, especially anatomical accuracy, text, and photorealism, matters more than workflow portability, or when you're building API-connected pipelines where Flux's clean model API is an advantage over running SD locally.