Settlement and fixing calendars (payment schedules from a system like Summit) need only be defined at run-time, so they can be created as objects of BespokeCalendar.
You would need to map the calendars of a proprietary system to QuantLib. I have one for all of the Base Summit calendars (102 in all), the QuantLib basic calendars (36) and the QuantLib calendar implementations (51).
This also has a mapping of the calendars (QuantLib to Summit) for only those that are used for the Ibor Index class.
For example, QuantLib::TARGET maps to EUR, and QuantLib::UnitedKingdom maps to LON.
The Ibor Calendars need to be corrected before they are used so that they match up with the Summit ones.
Most of the Summit base calendars, DUB for example, will be built at run-time as a BespokeCalendar from the Summit holiday listing.
Building a Calendar is a potentially recursive operation. The Summit calendar LPB is the union of BRU, DUB, EUR, LON, LUX, PAR. Only EUR and LON would be base calendars from QuantLib. The others would have to be read in.