Move from A1111 without moving the failure
Keep the working AUTOMATIC1111 install intact. Build Forge beside it, reuse only the model library at first, then prove every setting, extension and workflow before you call the migration complete.
Install beside. Reference models. Rebuild the rest.
Use a separate Forge folder and a separate venv. Prove Forge starts clean, then add --forge-ref-a1111-home. It maps seven expected model-related paths; it does not migrate settings, extensions, output history or Python packages.
Keep A1111 as the rollback. Recreate essential settings and install extensions one at a time. Similar controls reduce the learning jump, but they do not make two environments interchangeable.
What do you actually need to move?
Choose the dependency that would make you return to A1111. The route changes when the model library is the only requirement, an extension is essential, or the old installation is already unstable.
Reuse the model library without moving it.
First prove that a separate Forge installation opens with its own environment. Then add --forge-ref-a1111-home and verify each resolved category. The helper maps seven expected A1111 paths; it is not a universal models-folder switch.
Configure the model referenceTreat the move as an acceptance test.
Keep A1111 unchanged, record one known-good job, install Forge separately, reuse only the model files, and prove every required workflow. A similar interface is not proof that settings, scripts, API clients, or outputs are equivalent.
Start the migration protocolTest the exact extension, repository and commit.
Do not copy or link the whole A1111 extensions directory. Forge moved to Gradio 4 and changed backend contracts. Install one current Forge-compatible candidate only after the clean Forge baseline succeeds.
Use the extension gateCreate Forge as a separate diagnosis, not a repair.
Preserve the A1111 error, source revision and user data. Build Forge in another folder with its own venv and one known model. Only reference the old library after Forge starts clean; otherwise the source of the failure becomes ambiguous.
Open the failure mapEight records make the trial reversible.
Check an item only when its evidence exists outside the installation you are about to test. This planner stores nothing and changes no files.
Complete the checks to create a handoff receipt.
A familiar surface hides different dependency state.
Forge shares A1111 lineage and much of its interaction model. The current snapshots still require different runtime packages and expose different backend contracts.
Different environments
At the inspected commits, Forge pins Gradio 4.40.0, FastAPI 0.104.1 and Transformers 4.46.1; A1111 pins Gradio 3.41.2, FastAPI 0.94.0 and Transformers 4.30.2. Their default Torch commands also differ.
Extension similarity is not a guarantee
The maintainer reported roughly 70% of tested extensions working when Gradio 4 landed on 26 July 2024. That was one dated sample. The later temporary replacement list exists because repositories diverged.
An early official discussion included a shared-venv example. Current dependency evidence makes that unsafe as a general migration instruction. Reuse model files; isolate executable code and packages.
Decide each asset by behavior, not folder size.
Models are read-only assets in this trial. Settings and executable extensions can change behavior, so they cross the boundary only after the clean baseline.
| Asset | Action | Migration rule |
|---|---|---|
| Checkpoints | REFERENCE | Mapped from models/Stable-diffusion when that path exists. Confirm the same file and hash in both UIs. |
| VAE files | REFERENCE | Mapped from models/VAE. An explicit --vae-dir wins over the helper. |
| LoRAs | REFERENCE + VERIFY | The inspected helper checks models/lora. Case-sensitive systems can skip an A1111 models/Lora directory. |
| Embeddings | REFERENCE | Mapped from the A1111 embeddings directory when it exists. Compatibility still depends on the loaded model family. |
| Hypernetworks | REFERENCE + VERIFY | Mapped from models/hypernetworks; support in a current workflow must still be tested. |
| ControlNet assets | PARTIAL REFERENCE | The helper expects models/ControlNet and the old extension annotator/downloads path. Other layouts need an explicit path and a separate ControlNet test. |
| Upscaler models | NOT IN HELPER | ESRGAN, RealESRGAN and other upscaler folders are not in the seven-path helper. Configure or copy only what a proven workflow requires. |
| Prompt styles | COPY LATER | Back up both styles.csv files. Import or merge user styles only after the clean Forge baseline; do not overwrite new Forge styles blindly. |
| config.json / ui-config.json | REBUILD | Keep them as evidence, but do not replace Forge settings wholesale. Recreate required settings deliberately. |
| Extensions and scripts | REINSTALL ONE | Use a current Forge-compatible repository and exact commit. Never share or bulk-copy the extensions directory. |
| venv | NEVER SHARE | Forge and A1111 snapshots pin different Gradio, FastAPI, Transformers and Torch versions. Each installation needs its own environment. |
| Outputs | LEAVE IN PLACE | Previous images are records, not runtime dependencies. Keep the A1111 output tree intact and use a copy of the baseline PNG for comparison. |
Change one ownership layer at a time.
This protocol optimizes for a trustworthy answer: either Forge completes your actual job, or A1111 remains available with the reason documented.
- 01
Freeze the working A1111 state
Stop generation, save the current launch command and source identity, export or copy valuable user data, and preserve one known-good PNG with metadata. Do not update A1111, its extensions, the driver or Torch during this migration test.
- 02
Write the acceptance list
Name the jobs that make A1111 useful to you: model family, txt2img or img2img, inpainting, ControlNet, upscaling, extensions, scripts and API clients. “The UI opens” is not a complete migration.
- 03
Install original Forge separately
Use a new folder from lllyasviel/stable-diffusion-webui-forge. Let Forge create its own venv. Do not place Forge inside A1111 and do not reuse the A1111 venv even if an old example shows it.
- 04
Prove a clean Forge start
Launch Forge before adding shared paths or extra extensions. Success means the console stays alive and the interface opens. Record the Forge commit, Python/Torch environment and launch arguments.
- 05
Reference the A1111 model library
Add --forge-ref-a1111-home to the Forge launcher only. Quote any path that contains spaces. Start Forge and read every “Path … does not exist. Skip setting …” message instead of assuming the whole library was mapped.
- 06
Verify each inventory independently
Confirm one checkpoint, VAE, LoRA, embedding and ControlNet model only if you actually use that category. A visible checkpoint does not prove LoRAs, ControlNet or upscalers were found.
- 07
Repeat the minimal baseline
Use the same checkpoint file, prompt, negative prompt, seed, dimensions, sampler/scheduler where available, steps, CFG and batch size 1. Keep extensions, Hires.fix and ControlNet off. Record the Forge result and metadata.
- 08
Add one dependency at a time
Recreate only essential settings. Then install one extension or reconnect one client, restart, and repeat its smallest real job. Stop at the first failure and return to the clean baseline.
- 09
Prove the return path
Stop Forge, start the unchanged A1111 launcher, and repeat the saved A1111 baseline. Keep A1111 until every required Forge job passes and the user data has an independent backup.
Prove the task, not a speed headline.
The first comparison answers whether the shared model loads and a minimal job completes. It does not establish a universal performance or image-quality winner.
Exact checkpoint file and VAE; record the model hash when available.
Prompt, negative prompt, seed, dimensions, sampler/scheduler, steps and CFG.
Batch 1; no Hires.fix, ControlNet, LoRA or extra extensions.
Commit, Python/Torch, elapsed time, console result and output metadata.
The model path and clean generation work.
Now add one required setting, LoRA, extension or client and repeat its smallest meaningful job.
The clean baseline fails.
Do not import settings or extensions. Capture the first console error and use the relevant Forge troubleshooting route.
An extension migrates only when its job passes.
The extension folder contains executable code and dependencies. Treat every repository as a new integration, even when its name matches the A1111 extension.
- 1Name the job.
Write the exact function you need—not merely the extension name.
- 2Find the current owner.
Check the extension repository for an explicit claim about original Forge and the relevant Gradio generation.
- 3Install one repository.
Record its URL and commit. Do not copy the A1111 directory or its venv packages.
- 4Run the smallest real job.
Restart Forge, repeat the clean baseline, then perform the extension-specific action.
- 5Remove on first regression.
If startup, UI or output breaks, disable the new extension and verify that the baseline returns.
Its entries are dated reports and replacements, not a promise that every listed repository works with your current commit, model and extension set.
Use partial success to locate the boundary.
The helper intentionally skips missing directories. A partial library is evidence about one path, not proof that migration failed everywhere.
01Forge opens but no A1111 models appear
Confirm the argument is on the Forge launch line and points to the A1111 root, not its models subfolder. Quote spaces and read the skipped-path messages.
02Checkpoints appear, but LoRAs do not
Inspect the resolved LoRA path and capitalization. The current helper checks models/lora; Linux and other case-sensitive filesystems distinguish it from models/Lora.
03ControlNet models are missing
The helper checks A1111-home/models/ControlNet, not every historical extension-local layout. Use an explicit --controlnet-dir only after confirming the real folder.
04Upscalers are missing
This is expected from the helper alone: upscaler paths are not in its seven mappings. Configure the required upscaler inventory separately.
05Forge UI breaks after copying extensions
Remove or disable the copied extensions and relaunch with extra extensions disabled. Reinstall only one current Forge-compatible repository at a time.
06Forge changed settings unexpectedly
Restore the clean Forge settings backup. Do not reuse A1111 config.json or ui-config.json wholesale; recreate only the setting required by the tested job.
07The same prompt produces a different image
Verify the exact model file, VAE, seed, dimensions, sampler/scheduler, steps, CFG, model-family preset and all active extensions. Pixel identity is not guaranteed across different backends and versions.
08A1111 no longer starts after the test
Check whether its venv, launcher, source or model paths were modified. A safe migration does not change them; use the preserved state and troubleshooting evidence instead of altering Forge too.
Rollback is a launcher, not an uninstall.
When A1111 remains intact, returning does not require moving the shared model library or deleting Forge.
End the console process and free the local port and GPU memory.
Use the preserved launcher and unchanged venv.
Confirm the known-good job still completes.
Keep, retry later, or continue migration with the failed dependency named.
Do not delete A1111 merely because Forge opens. The migration is complete only when every required job passes and the return test proves your old environment was not changed.
Questions that appear after the first shared checkpoint.
These answers separate model discovery, environment isolation, workflow equivalence and extension compatibility.
Can I install Forge without deleting AUTOMATIC1111?
Yes. The safer evaluation keeps A1111 unchanged in its own folder and installs original Forge separately with its own virtual environment. Stop one UI before starting the other during baseline testing.
Can Forge use my existing AUTOMATIC1111 models?
Yes. The current original Forge code includes --forge-ref-a1111-home, which conditionally maps seven expected A1111 paths for checkpoints, VAE, hypernetworks, embeddings, LoRAs, ControlNet models and ControlNet preprocessor downloads.
Where do I add --forge-ref-a1111-home on Windows?
Add it to COMMANDLINE_ARGS in the Forge webui-user.bat, not the A1111 launcher. In the official one-click layout that launcher is inside the Forge webui folder. Preserve any existing Forge arguments and quote paths containing spaces.
How do I test the A1111 model path on Linux or macOS?
From the separate Forge checkout, launch ./webui.sh --forge-ref-a1111-home "/absolute/path/to/stable-diffusion-webui". After the test passes, place the argument in the Forge user launcher without replacing required platform defaults.
Does --forge-ref-a1111-home share every model folder?
No. The inspected helper maps seven exact paths. Upscaler folders and newer or custom inventories are not universal. Missing expected folders are skipped, and explicit directory arguments take precedence.
Why does Forge see checkpoints but not LoRAs?
The current helper expects models/lora. A1111 defaults and user folders can use models/Lora. That difference is invisible on normal Windows filesystems but matters on case-sensitive systems. Inspect the actual launch log and resolved path.
Can A1111 and Forge share the same venv?
Do not do this. The inspected Forge and A1111 snapshots require materially different package versions, including Gradio 4.40.0 versus 3.41.2 and different Torch defaults. A shared venv makes either launcher able to change the other environment.
Can I copy all A1111 extensions into Forge?
No compatibility guarantee supports a bulk copy. Forge changed its backend and moved to Gradio 4. Keep a clean Forge baseline, then install one essential extension from a current Forge-compatible repository and test its exact commit.
Does the old 70% extension compatibility number still apply?
No current guarantee follows from it. The maintainer reported about 70% in one test on 26 July 2024 when Gradio 4 landed. Treat that number as a stale snapshot, not a migration probability.
Can I copy config.json and ui-config.json?
Keep them as a record of A1111, but do not overwrite Forge with them wholesale. They can contain settings and component keys tied to a different backend, Gradio generation or extension set. Recreate only the settings your acceptance test requires.
Can I move my styles.csv?
Yes, after the clean baseline and with backups of both files. Merge or import user styles deliberately so Forge-specific or newly created styles are not overwritten. Test one style before treating the import as complete.
Will the same seed and prompt make the identical image?
Do not use pixel identity as the only pass condition. First align the exact model file, VAE, seed, dimensions, sampler/scheduler, steps, CFG, preset and extensions. Different backend or package versions can still change output.
Should I copy my A1111 outputs into Forge?
No. Leave the original output tree intact. Copy only the baseline PNG needed for comparison, and preserve its metadata. Previous outputs are evidence and user data, not a Forge runtime dependency.
Can both UIs run at the same time?
They can be configured on different ports, but do not run them together during a controlled baseline: both can compete for GPU memory and the default local port. Stop one process before starting the other.
What if Forge cannot find ControlNet models?
Check the actual A1111 location. The helper expects models/ControlNet and a specific extension annotator/downloads directory. Historical extension-local model folders or custom paths may require an explicit --controlnet-dir and a separate ControlNet test.
What if an essential A1111 extension has no Forge version?
Keep using the working A1111 installation for that job. A migration is not complete when a required dependency is missing. Re-evaluate only when the extension owner or a clearly identified replacement supports the exact Forge build you will use.
How do I return to A1111 after testing Forge?
Stop the Forge process and start the unchanged A1111 launcher. Because the repositories, venvs and user configuration stayed separate, rollback does not require uninstalling Forge or moving the shared model files.
When is it safe to delete A1111?
This guide does not require deletion. Consider it only after every required workflow, extension and client passes in Forge, the return test succeeds, and all user data has an independent backup. Shared models should not have A1111 as their only undocumented owner.
Code decides paths. Tests decide your migration.
Product behavior comes from the original repositories and code. Tutorials and community reports were used for vocabulary, failure states and rejected shortcuts—not as universal guarantees.
Primary and direct evidence · 12
Project identity, installation boundary and the advanced A1111-related route.
Current source snapshot used for code checks: dfdcbab6.
Definition of --forge-ref-a1111-home and individual directory arguments.
Seven conditional A1111 mappings, skipped missing paths and explicit-argument precedence.
Forge-side dependency versions used to reject a shared venv.
Upstream-side dependency versions used for the environment comparison.
Default data, models, extensions and outputs roots.
Origin and intended scope of the A1111 reference helper.
Published inventory list plus dated limitations reported by users.
Maintainer explanation of the shared lineage and different implementation.
Dated extension-compatibility warning and stale 70% test.
Discovery aid for Forge-specific repositories, not a universal compatibility matrix.
Research-catalog and fresh-search evidence · 8
A1111 reference command and recurring partial-path questions; performance claims rejected.
Transcript checked: separate package/Git install, models and familiar UI; broad speed claims rejected.
Transcript checked: migration and model-path intent; delete-A1111 advice rejected.
Transcript checked: disk duplication problem and symlink proposal; helper flag preferred for A1111-shaped storage.
Saved audit/transcript: multi-UI storage and third-party package risk.
Community symptom vocabulary; anecdotal and not a product-wide result.
Migration-cost intent and essential-extension concern; metadata/community evidence only.
Separate web search found the helper recommendation and its user job.
What was executed
Current helper code was run against complete and partial disposable A1111-shaped trees. Static source and dependency snapshots were compared.
What was not executed
No A1111-to-Forge GPU generation, extension compatibility, API parity or operating-system migration was run on this machine.
Editorial protocol
Side-by-side installation, delayed model reference and one-dependency tests are our reversible acceptance method; they are not an official migration guarantee.